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
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:
interfaceIPoint { val x:Double; val y:Double }
data classPoint(overridevarx:Double, overridevary:Double) : IPoint
that will be converted into:
value classPoint(valx:Double, valy: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.
The text was updated successfully, but these errors were encountered:
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.
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.
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:
that will be converted into:
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.
The text was updated successfully, but these errors were encountered: