Ok, so the main argument is that the change breaks to much stuff and therefore it doesn’t make sense to open an issue on github for a change in a future release?
The idea behind the question was, that if the #add() method will be moved to CalculusFieldElement interface and only renamed in FieldElement, the impact would only occur in classes BigFraction, BigReal and Fraction.
Is it then possible for other projects to manage such a renaming?
Or does it make more sense to introduce a more complete algebraic structure with a new “RingElement” interface like this one:
which inherits from interfaces AbelianGroupElem (with a #sum() method) and MonoidElem (with a #multiply() method)
If this is sufficient, it would be less disruptive for users, so yes I guess we could try that.
I also thought about all algebraic stuff a long time ago, but never implemented it as up to now we really had the need only for the field structure.
I think my point was missed. I didn’t say that the main argument against was API breaks. I meant that at the moment the naming across the whole Hipparchus library was consistent with itself as well as other Java components. And that’s important in my humble opinion.
Now, if what you’re proposing is to have an addition operator called sum for FieldElement and add for CalculusFieldElement, I find it very counterintuitive and NOT user-friendly, hence I strongly oppose it.
Not to mention that if we rename add into plus, we also need to update substract into minus.
Honestly, if there must be an API change, I’d be more inclined to have methods like radd and (l)add to let the possibility to define different operations from the right and the left sides respectively, like in Python for instance.