xkcd.com/927/
It is annoying that pretty much every gl framework also introduces its own vector types, which are embedded in their jar. Both Libgdx and Lwjgl, for instance. They're also typically somewhat sporadic in their feature set, since they're designed to solve specific issues for those frameworks.
In my humble opinion, commons.math doesn't contain that kind of math we need :-/
Definitely agree.
* I'm also not a big fan of static helper classes: people don't know about them, so they don't look at them.
The reason I think they are somewhat inevitable with a math library is otherwise you end up filling your math types with hundreds of methods, many of which are are somewhat business domain specific. This means you end up with a lot of methods to maintain in those classes. Splitting them out reduces the maintenance burden on that class. Note that none of those methods need private access to the Vector object.
Exactly where you draw the line is the question. I feel rotating a vector by a quaternion certainly should be in there (probably in the quaternion). Would you put lerp into a Vector? Slerp into quaternion (all three varieties)? Min/Max methods? Ultimately I like to think of a vector to be a math primitive like a float, so maybe not?
Unfortunately it seems to be a one-man show and the guy lost interest (no offense, but that makes it less attractive to use).
I very much agree. This is why, if we were to go ahead and make an independent math library, I would be inclined to make sure we can provide it sufficient support.
Final words: Maybe we can slowly replace vecmath by adding our own methods and classes just as guys have been doing over the past years. One example: a ConstPoint2i that throws UnsuppOpException just Collections.unmodifiable*() does.
In addition to license issues, this doesn't allow fixing the fundamental issues with vecmath, like methods that don't allow chaining, bad constructors, and the exposure of fields.
I have some concerns over the idea of a ConstPoint2i class as you describe. The reason I suggested an interface that is extended by the non-const Vector implementation (I don't like the Point name btw, but that is mostly a personal preference thing) is it allows a method to indicate whether or not it modifies the vector, so the caller knows whether it may want to do a defensive copy. A full Vector2i would implement the ConstVector2i interface (which suggests the name is probably bad, is there a good name suggestion it is the interface for the non-modifiable parts of a Vector?), so a Vector2i could be passed to a method requiring a ConstVector2i. An actual unmodifiable subclass means you would have to create a copy, and even if the jvm/GC handles short lived classes efficiently you would still be adding extra object creation over not doing that. You might as well just copy the Vector2i as another Vector2i and skip the ConstVector2i entirely, if ConstVector2i is a separate class or inherits Vector2i.
Having all vectors immutable is also sort of tempting but the resulting syntax for manipulation, particularly for individual dimensions, suffers as a result. For most of the other math classes I created - Rect2i, Region3i, and Color - I did go with immutability because that sort of individual dimension manipulation wasn't an issue, and manipulation in general wasn't as common.
