4 ms·

Is this opposite to the following opinion? > "“required” keyword in Protocol Buffers turned out to be a horrible mistake" https://capnproto.org/faq.html#how-d

Is this opposite to the following opinion? > "“required” keyword in Protocol Buffers turned out to be a horrible mistake" https://capnproto.org/faq.html#how-do-i-make-a-field-required-like-in-protocol-buffers https://capnproto.org/faq.html#how-do-i-make-a-field-require... Having both flexible, unvalidated parsing and validated parsing functions would probably be best IMHO.

dgb23 2y ago
The problem here as I understood it is more general and orthogonal to what the Parse, Don't Validate article is talking about. 1. A field being "required", is not a property of the field itself, but of the construct holding the field. JSON-Schema does this correctly, by letting you define an array of required fields on the schema of an object instead of it being a property of a specific field. 2. Consumers, not producers should decide what their assumptions are. Producers should decide what their guarantees are. 3. Everyone, including the parts in the middle (here it's a message bus) should only state assumptions that they actually need in order to function. Use different schemas for different assumptions (which is easier to do if the "required" assumption is a property of a construct and not a field). The example in the article you mentioned illustrates nicely how these three principles are broken by "required" (or maybe how Protocol Buffers are used in general).
- zigzag312 2y ago
  > 2. Consumers, not producers should decide what their assumptions are. Producers should decide what their guarantees are. Issue with schema definition languages is that only one set classes is generated. Forcing consumers to create large amounts of mapping logic to transform input to objects with required assumptions. I like the idea of an array of required fields on the schema of an object. Using arrays of required fields, could be used to generate different set of classes. That would make writing near-duplicate classes of input objects and mapping logic unnecessary.
lexicality 2y ago
No, the idea is that your application level validation functions take in data, own it and return a validation error or new type that has invalid states removed. In this case you could make a wrapper function that accepts the raw binary data, passes it to Cap'n'Proto, validates the output (this field is actually required etc) and then returns it
- zigzag312 2y ago
  Of course this is the correct way, but doing this manually is a lot of work. Ability to append validation schema to the input schema and have validation functions and valid-state types generated automatically would be a big boost in productivity.

dgb23 2y ago

The problem here as I understood it is more general and orthogonal to what the Parse, Don't Validate article is talking about. 1. A field being "required", is not a property of the field itself, but of the construct holding the field. JSON-Schema does this correctly, by letting you define an array of required fields on the schema of an object instead of it being a property of a specific field. 2. Consumers, not producers should decide what their assumptions are. Producers should decide what their guarantees are. 3. Everyone, including the parts in the middle (here it's a message bus) should only state assumptions that they actually need in order to function. Use different schemas for different assumptions (which is easier to do if the "required" assumption is a property of a construct and not a field). The example in the article you mentioned illustrates nicely how these three principles are broken by "required" (or maybe how Protocol Buffers are used in general).

zigzag312 2y ago
> 2. Consumers, not producers should decide what their assumptions are. Producers should decide what their guarantees are. Issue with schema definition languages is that only one set classes is generated. Forcing consumers to create large amounts of mapping logic to transform input to objects with required assumptions. I like the idea of an array of required fields on the schema of an object. Using arrays of required fields, could be used to generate different set of classes. That would make writing near-duplicate classes of input objects and mapping logic unnecessary.

lexicality 2y ago

No, the idea is that your application level validation functions take in data, own it and return a validation error or new type that has invalid states removed. In this case you could make a wrapper function that accepts the raw binary data, passes it to Cap'n'Proto, validates the output (this field is actually required etc) and then returns it

zigzag312 2y ago
Of course this is the correct way, but doing this manually is a lot of work. Ability to append validation schema to the input schema and have validation functions and valid-state types generated automatically would be a big boost in productivity.