This is in order to encourage methods accepting Vectors of both kinds, unless they explicitly need a mutable or immutable one.
The primary issue is that these class names are core to effectively all major dependents of this library, so this would have to come as part of a larger breaking API change.
Example usecase: I wanted to make org.terasology.math.Side (in the Terasology engine) return ImmutableVector3i instances instead of Vector3i (mutable) instances for the methods whose return value is marked in the javadoc as "Do not modify". Unfortunately, that is not possible without making everything using this vector accept BaseVector3i, and their dependencies, et cetera. At this point, I think it might be better to rename the classes as such to make it clearer what the intent is.
I would say MutableVector is kind of a mouthful. I might suggest switching
over to JOML, which has Vectorxx and Vectorxxc (where xx is the
dimension/type and c is for const).
This is in order to encourage methods accepting Vectors of both kinds, unless they explicitly need a mutable or immutable one.
The primary issue is that these class names are core to effectively all major dependents of this library, so this would have to come as part of a larger breaking API change.
Example usecase: I wanted to make org.terasology.math.Side (in the Terasology engine) return ImmutableVector3i instances instead of Vector3i (mutable) instances for the methods whose return value is marked in the javadoc as "Do not modify". Unfortunately, that is not possible without making everything using this vector accept BaseVector3i, and their dependencies, et cetera. At this point, I think it might be better to rename the classes as such to make it clearer what the intent is.