top | item 21873723

(no title)

seriesf | 6 years ago

Yes but proto 3 was also a mistake. Throwing away presence entirely was wrong and not preserving unknowns was also wrong. Proto 2 forever, imho.

discuss

order

xyzzyz|6 years ago

I agree. Preserving unknowns fortunately was recognized as mistake, and fixed in some more recent version, and presence can be worked around: it is still preserved for message types, so you only need to wrap your primitives into objects[1], Java style.

[1] - https://developers.google.com/protocol-buffers/docs/referenc...

lonelappde|6 years ago

That's not "agree" with "not preserving unknowns was also wrong."

abernard1|6 years ago

This gets to the article's issue but from the dynamic typing angle as well.

By not allowing presence checks, one has to use convention _in every single class_ to determine basic things like PATCH semantics (https://github.com/protocolbuffers/protobuf/issues/359). This makes it impossible to treat protobuf as a general data format and requires object-specific logic to properly composite data structures. In some cases it's impossible to even do PATCH correctly without excluding sentinel values from the allowed range and having the application developer know about it.

There are so many other problems with Proto v3, but this one is glaring.

rcfox|6 years ago

It can be approximated with a single-item `oneof` field. It's ugly and boilerplatey, but at least it's binary-compatible with proto2 and gives the original behaviour.

My main problem with proto2 these days is that I needed to interface with some C# code, and there is no proto2 library for C#!

mattnewton|6 years ago

Personally I even like this more since this feels much more explicit. The idea of depending on being set to the null value or unset at all gets my spider sense shivering and shuddering; someone is going to miss this, probably me.