Replies: 2 comments
-
The reason for this was that the focus in JOML's naming scheme and overall design has not been to be close to GLSL/GLM but rather close to other established Java matrix/vector libraries that existed around 2015, mainly:
Originally, JOML has been designed for people to migrate away from LWJGL 2's vector package, which was discontinued for LWJGL 3. So, in order for people to migrate to LWJGL 3 they needed an alternative to LWJGL 2's vector package. And JOML wanted to become that alternative. The above is not meant to argue in favor or against changing the naming scheme. It's just meant to provide the historic background about the decisions made which led to the current design. Relates to: #61 |
Beta Was this translation helpful? Give feedback.
-
Piggybacking on this one because I think this is interesting (im the OP, but my account got nuked) I recently tried playing with project Valhalla's value objects preview builds. Vector and matrix classes are obvious candidates for value classes. Only there is one tiny detail that prevents a smooth transition. Value classes are immutable. This forced me to introduce breaking changes. No more self modifying vectors. No more Long story short switching to immutable value types is undeniably a major breaking change that cannot be done seamlessly. To migrate a whole project is a huge undertaking, for sufficiently large projects it would be too hard to do in one step. That pushed me to create my own separate value classes for vectors/amtrices/quaternions that coexist with old mutable classes. And coincidentally - I named them Vec2, Vec3, Vec3i, Mat4, Quat, and so on - so that I can use both mutable Vector3f and immutable Vec3 at the same time in my client code as I incrementally ported it along. which reminded me of this thread and the whole naming dispute :) So I thought I need to bring this up. Since switch to value classes in the future will be most certainly a huge breaking change (and I think that cannot be swept under the rug, all client code will need attention andrewriting) maybe that's a good opportunity for JOML to change it's naming convention, at least for value classes - as they are something new that cannot be just seamlessly swapped in. |
Beta Was this translation helpful? Give feedback.
-
What is the reason that JOML decided to adapt different naming convention than the one in GLSL/GLM?
I find it wierd that JOML, being a library meant to be primarly used with OpenGL/LWJGL hasn't chosen a matching naming convention, for example like GLM did in C++ land.
What I mean is that it would feel more natural to interact with both GLSL and JOML if the naming convention was at least a little bit more similar. That is: keep names shorter and treat float as implicit default.
Vector3f -> Vec3
Vector3d -> Vec3d
Before I found JOML I was working on my own math library with exact that name convention, but now that I switched to JOML it's been bugging me all the time.
It's been bugging me so much that I seriously contemplated creating a fork called JOML-short or something.
I understand that switching the naming convention in 2.x is out of the question, as it would break too many things that depend on it, but what about next gen, JOML 3.0?
Beta Was this translation helpful? Give feedback.
All reactions