Skip to content

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

@kyay10

Description

@kyay10

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions