Proposal: State objects

Requirements

• Cartesian position & velocity vectors, classical Keplerian elements, Two-Line Elements?
• Transparent conversion of properties

>>> r = [-6045, -3490, 2500] * u.km
>>> v = [-3.457, 6.618, 2.533] * u.km / u.s
>>> leo = State.from_cartesian(Earth, r, v)
>>> leo.ecc
<Quantity 0.1712123462844536>

>>> a = 1.523679 * u.AU
>>> ecc = 0.093315 * u.one
>>> p = a * (1 - ecc**2)
>>> inc = 1.85 * u.deg
>>> raan = 49.562 * u.deg
>>> argp = 286.537 * u.deg
>>> nu = 23.33 * u.deg
>>> mars = State.from_keplerian(Sun, p, ecc, inc, raan, argp, nu)
>>> mars.r
<Quantity [  2.08047627e+08, -2.02006193e+06, -5.15689300e+06] km>

Other:

• Ease of implementation ("keep the class hierarchy as lean as possible")
• Possibility to change reference frame? (See "Notes" below)
• Good performance? (Compared to what?)

Proposals

#1: Different classes: CartesianState, KeplerianState

Pros:

• API more similar to what Orekit does
• Might lead to simpler implementation

Cons:

• Not possible to mix with other concepts for subclasses (e.g.: reference frames)

#2: Different constructors: State.from_cartesian, State.from_keplerian

Pros:

• API makes clear that all objects are the same, only instantiation differs
• Can use subclasses for different purposes (e.g.: reference frames class ECIState(State))

Cons:

• Implementation problems:
  • Storing only cartesian vectors may lead to redundant conversions, poliastro 0.3 resorts to accessing to a protected property https://github.com/poliastro/poliastro/blob/v0.3.1/poliastro/twobody/state.py#L123
  • Current implementation in poliastro 0.4 suffers from circular imports and lack of encapsulation https://github.com/poliastro/poliastro/blob/v0.4.2/src/poliastro/twobody/core.py#L381

Retort:

• "Implement caches in the right places, after proper profiling"

Notes

Regarding the change of reference frame, it may not have sense for some types of State. The most obvious case are the classical Keplerian elements, which are only valid in a body-centered inertial frame. In fact, this might be sensible only for cartesian position-velocity vectors.

I think we can reject frames that aren't pseudo-inertial, in this case, allowing user to provide any pseudo-inertial frame.