Closed cmleinz closed 1 year ago
Yep, in the case of spk::position
returning Result<(Rectangular, SpiceDouble)>
instead makes sense to me.
And for the others e.g. spk::easy_reader
do you mean returning Result<(Rectangular, Vector3D, SpiceDouble)
>` ?
Possibly even a struct may make more sense, since having a complex tuple can be a bit confusing?
struct State {
position: Rectangular,
velocity: Vector3D,
light_time: SpiceDouble
}
I think also we should also change the definition of Rectangular to be completely independent of Vector3D?
/// Rectangular coordinates
#[derive(Copy, Clone, Debug, Default, PartialEq, From, Into, Deref, DerefMut)]
pub struct Rectangular([SpiceDouble; 3]);
Feel free to raise a PR or otherwise I am happy to look at it in the next few days
Great! That sounds like a good prescription. I'll work this and submit a PR sometime this week.
Should functions which return position and light time be returned as a tuple Result<(Rectangular, SpiceDouble)>
and ones which return state return Result<State>
? Or should ones which return state return Result<(State, SpiceDouble)>
, where State
is:
struct State {
position: Rectangular,
velocity: Vector3D
}
and SpiceDouble
is the light time
Hey Jacob! Currently the return type for
spk::position
and other similar functions is aVector3D
.However the CSPICE documentation says the following:
Perhaps we should return
Rectangular
so as to streamline the conversion to different coordinate systems. Something like:Optionally we could also break apart the return type of functions which return
[SpiceDouble; 6]
into their position (Rectangular)