Should we turn methods on VecX objects into extensions (Java Interop)?

[kyay10]

trafficstars

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:

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