You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's some experimentation happening with adding interfaces into the VecX hierarchy to allow distinguishing between mutable and read-only vectors.
While working on this, I encountered issues with glm's usage of inline methods inside the VecX classes. We define a lot of convenience functions on every vector (like plus, minus, etc) and all of which can be turned into extension functions. The benefits of turning them into extensions include:
It's the "recommended" approach in Kotlin to only include the "main" declarations of a class inside of it, and make any "convenience" functions extensions (which, design-wise, helps ensure that the interface a class provides is exactly what that class needs to expose).
It would allow those inline functions to be defined for the upcoming read-only interfaces (because interfaces in kotlin can't have inline functions)
The disadvantages include:
Java interop would be uglier (e.g. Vec4 result = myVec4.times(myOtherVec4); would become Vec4 result = Vec4Kt.times(myVec4, myOtherVec4);
Imports will be needed for the extensions (IDEA will handle this automatically)
So, this issue is to gather feedback on whether Java Interop matters much to you. As a compromise, we can make just the inline functions into extensions.
The text was updated successfully, but these errors were encountered:
Hello,
There's some experimentation happening with adding interfaces into the
VecX
hierarchy to allow distinguishing between mutable and read-only vectors.While working on this, I encountered issues with glm's usage of inline methods inside the VecX classes. We define a lot of convenience functions on every vector (like plus, minus, etc) and all of which can be turned into extension functions. The benefits of turning them into extensions include:
inline
functions to be defined for the upcoming read-only interfaces (because interfaces in kotlin can't haveinline
functions)The disadvantages include:
Vec4 result = myVec4.times(myOtherVec4);
would becomeVec4 result = Vec4Kt.times(myVec4, myOtherVec4);
So, this issue is to gather feedback on whether Java Interop matters much to you. As a compromise, we can make just the inline functions into extensions.
The text was updated successfully, but these errors were encountered: