4 ms·
- removing optional values is actually quite nice. In practice, I end up checking for "missing or empty string" anyway. - the "well-known types" boxed primitiv
by zellyn 10y ago
- removing optional values is actually quite nice. In practice, I end up checking for "missing or empty string" anyway.
- the "well-known types" boxed primitive types essentially add optional values back in. And depending on your language bindings, may look the same.
- extensions are still allowed in proto3 syntax files, but only for options - since the descriptor is still proto2. It seems odd to build a proto3 that couldn't represent descriptors.
- I still don't understand the removal of unknown fields. Reserialization of unknown fields was always the first defining characteristic of protobufs I described to people. I actually read many of the design/discussion docs internally when I worked at Google, and I still couldn't figure this one out. Although it's certainly simpler…
- Protobufs are the "lifeblood" (Rob Pike's words) of Google: the protobuf team is working to get rid of significant Lovecraftian internal cruft, after which their ability to incorporate open source contributions should improve dramatically.
- tantalor 10y ago> removing optional values Slight correction: optional values are not removed. Quite the opposite; the "optional" keyword is removed because now all fields are optional. It is actually required values which were removed.
- zellyn 10y agoTrue. But when using them, it feels like every field is "present" and you don't have to worry about the "optional, missing" case.
- tantalor 10y agoFor primitives, yes, but not messages.
- honkhonkpants 10y agoYou're both right. What has been removed is the concept of presences altogether.
- teacup50 10y ago> - removing optional values is actually quite nice. In practice, I end up checking for "missing or empty string" anyway. I feel the opposite; this greatly reduces the utility of protobuf. Previously, I could trust that if parsing succeeded, then I had a guarantee of a populated data structure. Now, I have to check each field individually, in manually written code, to verify that no required fields are missing. That's really lame, and a huge step backwards.
- peq 10y agoI agree. In particular in languages without null you will have a lot of Option types in the mapping. You no longer can generate useful type definitions from the proto spec.
- madgar 10y ago> Now, I have to check each field individually, in manually written code, to verify that no required fields are missing. You always had to check the individual fields for the zero value. A required field in a proto2 message can be set but also have the default value and pass initialization.
- cbsmith 10y agoI think you wording is a bit difficult to parse. Does this convert what you are trying to say: In proto2, default values are for optional fields. The value of an optional field would be that value, but there's a separate concern as to whether that field had been set.
- teacup50 10y ago> You always had to check the individual fields for the zero value. No, you didn't. A required field has a value, period. If it defaults to a particular value, then that's the value it has. If you had a non-required field, then you marked it 'optional', and checked for the field's existence (or mapped optional fields to a Maybe/Option monad representation, forcing the issue).
- cbsmith 10y ago