Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
kyay10 opened this issue Apr 28, 2023 · 0 comments
Open

Comments

@kyay10
Copy link
Collaborator

kyay10 commented Apr 28, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant