To address issue-778, which requires updating pole definitions according to the IAU WGCCRE 2015 report, I went through the commit history and noticed that PredefinedIAUPoles was changed from an enum to an abstract class , and now uses timescales as an explicit parameter instead of TimeScalesFactory .
However, I believe that (1) an enum would be more concise and clear for PredefinedIAUPoles , and (2) using TimeScalesFactory would allow omitting the timescales parameter when constructing a PredefinedIAUPoles instance.
Could someone provide a clue to the thought behind these changes? Otherwise, I might end up making the same mistake again.
Both changes were motivated by the introduction of an explicit time scale to the class.
This is part of a greater change that @evan.ward tackled a while ago (for version 10 if I remember well).
The idea was to allow users to define a custom DataContext different from the default data context. Doing that meant passing explicitly as input the objects usually handled by the default context factories (time scales, frames, gravity fields etc.).
For example, JPLEphemeridesLoader, which is the sole caller of PredefinedIAUPoles.getIAUPole method has two constructors, a simple one using calls to the default data context (with the @DefaultDataContext tag), another one using explicit inputs to time scales, the GCRF frame, and the data provider manager.
If you look into the code (search for @DefaultDataContext for example) you’ll see many examples like this one.
This duplication was mandatory to allow more control on the data contexts.
Note also that there are other places where we switched from an enumerate to something else (in fact an interface) plus an enumerate that implements the interface.
Some examples are TargetProvider (the associated enumerate being PredefinedTarget) that is used for AlignedAndConstrained attitude mode, ObservationType (the associated enumerate being PredefinedObservationType) used for GNSS observables, or TimeSystem (the associated enumerate being PredefinedTimeSystem) also used in GNSS context.
This allows users to provide additional implementations apart from the ones defined in the enumerate. As enumerate cannot be extended and cannot extend another class, the class hierarchy has to start at a higher level.