Protodef Switches are a confusing type

[nickelpro]

Protodef Switches are used to encode three distinct ideas right now and it's really burdensome to build a code generator that cleanly does all three.

The first and most natural use for the switch is a sum type, such as entity metadata.

The second is a multi-element switch, which is a set of consistent types some or all of which are en/decoded depending on the compareTo variable. An example for this is the Boss Bar packet.

The final type is an optional type, which is a single consistent type that is en/decoded based on compareTo. An example is the Advancements packet.

The way you naively want to approach serializing, deserializing, and representing these three in strongly typed languages is different. Sum types want to be stored in a union and accessed with a switch, multi-elements want to be stored as a struct/class and accessed with a switch, and optionals want to be stored as a single field and accessed with a conditional or something like std::optional.

I've built a (very poor) generator for C and am currently building a (hopefully better) one for C++. In both switches are by far the most complicated structure to parse, and require introspection to try to merge multi-element-type switches.

This issue is mostly me complaining, feel free to close. I don't think Protodef has the required machinery to describe the latter two types I've laid out here, and switches are being used as crude kludge. In JS it likely doesn't matter, so I can understand this being a non-priority.

[rom1504]

I think this was addressed in protodefc language. They were explicit union types there. Maybe you could have a look at what was done there and see if we could create new types that would make more sense to replace switch ? If we had that kind of thing it could be possible to automatically replace the switch we have to these types and then deprecate switch. But first things first, finding these better types and comparing them with switch would make things clearer here :)

…

On Sun, Jul 26, 2020, 05:56 Vito Gamberini ***@***.***> wrote: Protodef Switches are used to encode three distinct ideas right now and it's really burdensome to build a code generator that cleanly does all three. The first and most natural use for the switch is a sum type, this is what it's used for in entity metadata <https://github.com/PrismarineJS/minecraft-data/blob/master/data/pc/1.16.1/protocol.json#L172-L236> . The second is a multi-element switch, which is a set of consistent types some or all of which are en/decoded depending on the compareTo variable. An example for this is the Boss Bar packet <https://github.com/PrismarineJS/minecraft-data/blob/master/data/pc/1.16.1/protocol.json#L1197-L1265> . The final type is an optional type, which is a single consistent type that is en/decoded based on compareTo. An example is the Advancements packet <https://github.com/PrismarineJS/minecraft-data/blob/master/data/pc/1.16.1/protocol.json#L994-L1001> . The way you naively want to approach serializing, deserializing, and representing these three in strongly typed languages is different. Sum types want to be stored in a union and accessed with a switch, multi-elements want to be stored as a struct/class and accessed with a switch, and optionals want to be stored as a single field and accessed with a conditional or something like std::optional. I've built a (very poor) generator for C <https://github.com/SpockBotMC/mcd2c> and am currently building a (hopefully better) one for C++. In both switches are by far the most complicated structure to parse, and require introspection to try to merge multi-element-type switches. This issue is mostly me complaining, feel free to close. I don't think Protodef has the required machinery to describe the latter two types I've laid out here, and that switches are being used as crude kludge to make it work. In JS it likely doesn't matter, so I can understand this being a non-priority. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#312>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAR437QPWGBRVY6Z576WITDR5OSPJANCNFSM4PHY2JMQ> .

[nickelpro]

Not the repo to fix this in