Eliminate boxing of protocol types for serialization #2330
Conversation
We still have a few cases of use within a Zipline interface that causes it, but those are rarely invoked (protocol mismatch handlers).
| Note: The types in this file are written in a careful way such that their serializable properties | ||
| are scalars which can be serialized directly rather than using value classes are boxed within the | ||
| generated kotlinx.serialization code. |
There was a problem hiding this comment.
I don't love this, but kotlinx.serialization boxes every value class instance on both serialization and deserialization paths, and this avoids that without changing the public API (aside from invoke vs constructor).
| public abstract fun removeWidget(id: Id) | ||
|
|
||
| @RedwoodCodegenApi | ||
| public val childrenVisitor: ProtocolWidget.ChildrenVisitor = if (synthesizeSubtreeRemoval) { |
There was a problem hiding this comment.
Allocate only once, rather than once per children wrapper.
| removedIds: List<Id> = listOf(), | ||
| removedIds: List<Id>, |
There was a problem hiding this comment.
This caused boxing of the Id and ChildrenTag in JS if the caller omitted this last argument and relied on the default.
There was a problem hiding this comment.
Is there a way we can validate boxing doesn't occur in a test case? Or is it only possible when inspecting the generated code?
There was a problem hiding this comment.
I'll think about it. You definitely can see the boxing in a full compiler plugin, and maybe in FIR only. Probably also as a lint check.
Filed #2336
This deduplicates things, but it also prevents an initialization cycle which was causing the value to always be false.
We still have a few cases of use within a Zipline interface that causes it, but those are rarely invoked (protocol mismatch handlers).
#1040
CHANGELOG.md's "Unreleased" section has been updated, if applicable.