I am fine with this.
1 Like
Is it OK?
Think so, thanks.
1 Like
Last but not least, if we aggree with removing AdditionalStateProvider, I’ll of course do the change in the Field part to have the same names in interfaces and methods in Propagator and SpacecraftState.
Because having AdditionalData only for non-field and AdditionalState for field will be extremely confusing
Sorry I misunderstood I thought you were gonna mirror one for one the implementation for Field. Otherwise I would have said to keep the AdditionalStateProvider then.
I actually find confusing that for non Field you can add any Object and for Field it’s just array of Field. I’ve opened an issue to generalize.
Cheers,
Romain.
In fact the problem is that the field part was already generalized to any Field while the non-field was only suitable for double arrays. If one wants to use the field implementation (s)he just have to implement its own CalculusFieldElement.
I don’t think it is possible to have a more generic implementation. Or it would be something difficult by introducing Object class in the field interface.
Renaming was a minimum step, and a mandatory one at the end, because having two interfaces with different names could be very confusing.
Bryan
The idea for field would be to have FieldAdditionalDataProvider<O, <T extends CalculusFieldElement> with
O getAdditionalData(FieldSpacecraftState> state)
Any opinion is welcome
1 Like
The minimum effort is definitely to reintroduce (Field)AdditionalStateProvider. I think it’s way better to have an extra feature for non-Field that different features with the same name.
Job done! I generalized FieldAdditionalDataProvider to any object. That’s merged into develop and will be released with 13.0
3 Likes