Add a durationFrom method in TimeStamped

1

Hi all,

I would like to have your views on the following feature. Do you think it could be interesting to add a method durationFrom in TimeStamped interface?
It could be a default method like:

defaut double durationFrom(TimeStamped other) {
    return getDate().durationFrom(other.getDate());
}

Like that, the following code

AbsoluteDate date = ...
CartesianOrbit orbit = ...
SpacecraftState state = ...
Opm opm = ...
StateCovariance stateCovariance = ...

orbit.getDate().durationFrom(date);
state.getDate().durationFrom(date);
opm.getDate().durationFrom(date);
stateCovariance.getDate().durationFrom(state.getDate());

Could be replaced by

orbit.durationFrom(date);
state.durationFrom(date);
opm.durationFrom(date);
stateCovariance.durationFrom(state);

Thanks to this method, we could have simpler code and reduce the calls to getDate() method to compute durations.

Bryan

2

Good idea, +1

3

Sounds good.

Romain.

4

You have my :+1:

5

Thanks for your supports! Issue opened: Add TimeStamped#durationFrom method (#1139) · Issues · Orekit / Orekit · GitLab

6

Hi all,

To go further, could we add methods isBefore, isAfter, etc. for all TimeStamped inheritors?

Cheers,
Romain.

1 Like
7

Anything is possible. These methods can be default ones implements in the interface.

8

Actually I’m bothered by the current naming. Having a method isAfterOrEqual between two objects of different classes is misleading. Adding more of those would make it worse, so I think the best course of action is to await a major release to rename as isAfterOrSimultaneous for instance. Or we could already create them and deprecate the counterintuitive ones.

Cheers,
Romain.

9

This is already what we do with the durationFrom() method with two TimeStamped and I’m not bothered with it. At the opposite it is very useful because it limits the number of method call like .
Some checkstyle conventions, like ECSS, limit the number of caracters for a line. So, having those shortcut is really appreciated, even if the two objects are different (but they are both TimeStamped).

At the end, default implementations in TimeStamped will do timeStamped1.getDate().isBefore(timeStamped2.getDate()). So I’m in favor of conserving the original name!

So, I agreed at 100% with your first idea of having isBefore, isAfter, etc. like in AbsoluteDate class.

10

Well isBefore has a fine name, it’s when there is “equal” between two objects of totally different classes that I’m bothered. I prefer longer names if they are less ambiguous for the user. So I’d rather not add it with the current naming, but if someone must, they can. At the end of the day, it’s just syntactic sugar.

Cheers,
Romain.