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

Evaluate MFVC for KorGE 4.0 #1257

Closed
soywiz opened this issue Feb 2, 2023 · 2 comments
Closed

Evaluate MFVC for KorGE 4.0 #1257

soywiz opened this issue Feb 2, 2023 · 2 comments
Labels
Milestone

Comments

@soywiz
Copy link
Member

soywiz commented Feb 2, 2023

Multi Field Value Classes: Kotlin/KEEP#339

This will break compatibility (since we have mutable stuff, interfaces etc.), so it can only be considered for a major release.
Since 4.0 is still an alpha, we are still on time.

It has risks, but really really huge benefits and worth even using it as experimental.
To not depend on Kotlin timeline we could fallback to data class, accepting the performance penalty hit initially and manually crafting vector code in the time being inside the engine itself, and asuming it will "eventually" work faster and allocation-free.

The most evident example of this is:

interface IPoint { val x: Double; val y: Double }
data class Point(override var x: Double, override var y: Double) : IPoint

that will be converted into:

value class Point(val x: Double, val y: Double)

The IPoint interface will disappear, and Point will be immutable. The internal implementation will simplify a lot, and people will be able to do things like Point(1, 2) + Point(3, 4) fast and without allocations, so vector code won't require temporal points, and won't require hacks to look nice.

We can later change internal algorithms that are now inlined to use this, simplifying the implementation code a lot without affecting the exposed API.

Since 4.0 will exploit kproject for the first time a lot, doing this right now would reduce migrations to all the kprojects later.

@soywiz soywiz added this to the 4.0 milestone Feb 2, 2023
@soywiz soywiz added the task label Feb 2, 2023
@soywiz soywiz pinned this issue Feb 9, 2023
@soywiz
Copy link
Member Author

soywiz commented Feb 13, 2023

For now I'm going to go for renaming Point to MPoint, keeping IPoint and adding a new Point that doesn't implement any interface. Then keep methods using MPoint with a new name and mark them as deprecated, and adding new methods for Point. Then we can remove MPoint functionality later, while still allowing to use it in critical places before Point is fully used with MFVC.
We can do the same with other stuff like Rectangle, Matrix, etc.

@soywiz
Copy link
Member Author

soywiz commented Feb 26, 2023

As said, now there are mutable variants and interfaces, and the immutable without interfaces plain data classes prepared for value, so I'm closing this.

@soywiz soywiz closed this as completed Feb 26, 2023
@soywiz soywiz unpinned this issue Mar 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Archived in project
Development

No branches or pull requests

1 participant