4 ms·
No they’re not, they’re a horrible decision, and some of the “solutions” I’ve seen for working around them are band-aid-code at best. The design decisions arou
by FridgeSeal 3y ago
No they’re not, they’re a horrible decision, and some of the “solutions” I’ve seen for working around them are band-aid-code at best.
The design decisions around zero values infect protobufs too, and they suck to work around. The fact that an empty message can successfully deserialise into any valid protobuf is an insane decision and should have been thrown out long ago.
- znkr 3y ago> The fact that an empty message can successfully deserialise into any valid protobuf is an insane decision and should have been thrown out long ago The reason for this is that the protobuf wire format is designed for very high entropy: It contains only a minimal amount of metadata and consists mostly of data. This means you can deserialize most wire messages as a different message. This is a tradeoff: smaller message size for loss of schema information. This just means that schemas need to be handled at a higher level. This tradeoff makes some sense if you process millions of protos per second. BTW: Dismissing a tradeoff like this as insane is derogatory. You can do better
- campbel 3y agoThis is the main drawback I also experience with zero values, knowing whether something was set or its the zero value. Like I said, there are some work arounds, buts its a tradeoff. Perhaps its a tradeoff you don't like.