4 ms·

Mostly lost me at "Make all fields in a message required. This makes messages product types." Your constraints on protocols can change over time and context, c

Mostly lost me at "Make all fields in a message required. This makes messages product types." Your constraints on protocols can change over time and context, changing something that is required to something that is optional can cause crashes in prod. Unless somehow the 'optional' design has a way to handle that? You also will have to do custom validation anyways, as your storage format will never be able to enforce all constraints you care about. Also, it would seem like the 'debate' of optional vs required is harmful was resolved, as proto3 makes everything optional.

danharaj 8y ago
Like, 5 lines later: > For example, we can rebuild optional fields:
- _dmurph 8y ago
  How is this different than having both required and optional.
  - danharaj 8y ago
    It's explained. Later in the article.
vl 8y ago
If you would continue reading, there is an explanation of how optional would work almost immediately after this quote.
- _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.
deleted 8y ago
[deleted]

danharaj 8y ago

Like, 5 lines later: > For example, we can rebuild optional fields:

_dmurph 8y ago
How is this different than having both required and optional.
- danharaj 8y ago
  It's explained. Later in the article.

vl 8y ago

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

_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.

deleted 8y ago

[deleted]