MovingBlocks / TeraMath

Experimental standalone math and stuff. Automation category: Terasology Library
Apache License 2.0
13 stars 11 forks source link

Long-term refactor proposal: BaseVector -> Vector, Vector -> MutableVector. #51

Open asiekierka opened 6 years ago

asiekierka commented 6 years ago

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.

immortius commented 6 years ago

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).