5 ms·

If you would continue reading, there is an explanation of how optional would work almost immediately after this quote.

by vl 8y ago

_dmurph 8y ago
Right - this is the same as having the possibility of both required and optional. I'm saying there should not be any possibility of a 'required' field
- vl 8y ago
  In context of current protobuf design required was a mistake and optional is clearly better, but author argues about grand type system that is based on different principles, including stronger validation. Criticizing protobufs is like criticizing C++ or Java. Both have major shortcomings, but solve practical problems and de facto lingua franca with no practical solutions to replace them.
  - saalweachter 8y ago
    From a practical standpoint the problem is that "required" handles a trivial subset of message validation. I mean, I'm not going to claim that it never happens that your only constraint on a valid value of a message field is "present", but you quite often want to be able to require that one of three fields is set, or a number be between 0 and 1048576, or that a field be equal to an existing user ID, it that a string contain at least one printable non-punctuation, non-space letter. So no matter your RPC message parsing code, you're going to need a custom bit of code in each of your handlers to say "This isn't a valid message, fuck off". Enforcing "this field should be of this primitive type" saves a lot of time, but it turns out that "this field should exist" doesn't save that much because you still have to write "... and have a sensible value" in your own code. So you have a language feature which causes problems sometimes and doesn't really help much.
    - lmm 8y ago
      > it turns out that "this field should exist" doesn't save that much because you still have to write "... and have a sensible value" in your own code. Disagree. Dozens of "x should exist" checks are tedious to write and even more tedious to read, obscuring the more relevant business-specific validation logic. Better to move the low-hanging fruit into the message format.

If you would continue reading, there is an explanation of how optional would work almost immediately after this quote.

by vl 8y ago

If you would continue reading, there is an explanation of how optional would work almost immediately after this quote.

Right - this is the same as having the possibility of both required and optional. I'm saying there should not be any possibility of a 'required' field

vl 8y ago
In context of current protobuf design required was a mistake and optional is clearly better, but author argues about grand type system that is based on different principles, including stronger validation. Criticizing protobufs is like criticizing C++ or Java. Both have major shortcomings, but solve practical problems and de facto lingua franca with no practical solutions to replace them.
- saalweachter 8y ago
  From a practical standpoint the problem is that "required" handles a trivial subset of message validation. I mean, I'm not going to claim that it never happens that your only constraint on a valid value of a message field is "present", but you quite often want to be able to require that one of three fields is set, or a number be between 0 and 1048576, or that a field be equal to an existing user ID, it that a string contain at least one printable non-punctuation, non-space letter. So no matter your RPC message parsing code, you're going to need a custom bit of code in each of your handlers to say "This isn't a valid message, fuck off". Enforcing "this field should be of this primitive type" saves a lot of time, but it turns out that "this field should exist" doesn't save that much because you still have to write "... and have a sensible value" in your own code. So you have a language feature which causes problems sometimes and doesn't really help much.
  - lmm 8y ago
    > it turns out that "this field should exist" doesn't save that much because you still have to write "... and have a sensible value" in your own code. Disagree. Dozens of "x should exist" checks are tedious to write and even more tedious to read, obscuring the more relevant business-specific validation logic. Better to move the low-hanging fruit into the message format.