Hi Hank, and Evan [I combined your two messages to answer both options] Hank Grabowski <hank@applieddefense.com> a écrit :
What if instead of 1A do a TimeStamped decorator class? That way we could turn anything into TimeStamped without having potentially redundant class definitions. It can make the type definition a bit long with nested generics of course, but from an architecture standpoint it would be cleaner. So you could do something like: TimeStamped<PVCoordinates> or TimeStamped<AngularCoordinates>
This is interesting, but prevents using the new objects in place of the older one were it makes sense. I have started to look at the implications and used inheritance, which is the same thing Evan proposed below.
Evan Ward <evan.ward@nrl.navy.mil> a écrit :
+1 for 1a. If I understand correctly TimeStampedPVCoordinates would extend PVCoordinates, which would allow us to use the new class with old code. On a similar note, should we change the return type for PVCoordinatesProvider to TimeStampedPVCoordinates? It would create more backward incompatibilities because we are changing the return type of an interface, but the date information is available in this case.
I started exactly this way: having the new classes extend the existing ones using the classical pattern: a TimeStampedXxx "is a" Xxx.
As the class considered are really used in many places, it seemed appropriate, and also avoids partly the redundancy as some methods can be inherited. It is not magic, and some methods (mainly the ones that return a new instance) must be overriden so they build the new object type.
You are right about PVCoordinatesProvider, it would really make sense to change its return type. As next version will be a major one, we could porbably do this change. In fact, it will not be too cumbersome for existing code that simply use providers as the new objects will still be a PVCoordinates. It will break code that implements the interface, but I think there are far less new implementations than uses.
best regards, Luc
On Wed, Jun 11, 2014 at 5:39 AM, MAISONOBE Luc <luc.maisonobe@c-s.fr> wrote:Hi all, One of the lowest level data structure we use extensively in Orekit is PVCoordinates. It simply holds two vectors and thats all. The class was not intended to be used alone, as people most often need to associate it with both time (typically either an AbsoluteDate instance of an offset from some reference) and a Frame instance. When these more complete data are needed, we use slightly higher level objects, like CartesianOrbit for example. Another similar structure is AngularCoordinates, all the discussion below applies to both cases. However, I wonder if another intermediate level would be useful or not, with the date already associated with the two vectors (or rotation), but still without frames? There are several places in Orekit where this intermediate level is used, but up to now we relied simply on Pair<AbsoluteDate, PVCoordinates>, using the Pair<K,V> class provided by Apache Commons Math. This is cumbersome, and it does not implement TimeStamped, thus preventing us to collect a bunch of instances in a TimeStempedCache. As we often deal with a full ephemeris of PVCoordinates were all elements have a different date but all are in the same frame, letting the frame out of this seems fair to me. I can see several different ways to implement it: 1a) new classes TimeStampedPVCoordinates, TimeStampedAngularCoordinates ... 1b) internal classes : PVCoordinates.TimeStamped ... 1c) changing current PVCoordinates to add time I would personnally prefer 1a as it is simpler than 1b and allow to keep also non-dated PVCoordinates which are useful when the date is either not meaningful for constant positions or when it is in some upper level structure and could lead to some consistency problems if 1c were chosen. If time-stamped versions of these classes were available, we could also simplify the signature of the static interpolation methods (and probably move them to the new classes). What do you think about a new class at this level? best regards, Luc ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.