Gunk: Modern front end and syntax for Protocol Buffers

Post by LOLOLOLO1 » Sat, Jan 19, 2019, 10:25 PM UTC

kenshaw wrote: post #24

tybit wrote: post #13

Earlier quoted context omitted.

I just can’t get my head around this reasoning, it’s just as valid to ask for/return a “foo OR bar” as it is to ask for a “foo AND bar”. Any protocol that rejects that pushes that complexity elsewhere, somewhere less explicit.

I feel very strongly that type safety is of paramount importance in development, and "oneof" (and other similar constructs) in protocol design breaks fundamental ideas of type safety. It's a feature of the IDL that doesn't translate well to the actual implementing language, is not strictly necessary as the same thing can be accomplished through other designs that have an added benefit of being more explicit, both to…

"oneof" construction is here for two reasons:

1. It enhances readability 2. It would be a surprise to you: oneof actually enhances type safety. It is just lacking type system of Go where you cannot express the feature and thus loses type safety.

Post by atombender » Sun, Jan 20, 2019, 2:07 AM UTC

kenshaw wrote: post #24

tybit wrote: post #13

Earlier quoted context omitted.

I just can’t get my head around this reasoning, it’s just as valid to ask for/return a “foo OR bar” as it is to ask for a “foo AND bar”. Any protocol that rejects that pushes that complexity elsewhere, somewhere less explicit.

I feel very strongly that type safety is of paramount importance in development, and "oneof" (and other similar constructs) in protocol design breaks fundamental ideas of type safety. It's a feature of the IDL that doesn't translate well to the actual implementing language, is not strictly necessary as the same thing can be accomplished through other designs that have an added benefit of being more explicit, both to…

No, "oneof" increases type safety. "oneof" describes mutually exclusive fields. For example:

  message Filter {
    oneof kind {
      Tags tags = 1;
      IPRange ipRange = 2;
    }
  }

With this in place, a client has to check the type of the filter in order to access the actual filter:

  switch t := f.Kind.(type) {
    case *Tags:
      // ...
    case *IPRange:
      // ...
  }

Without it, you can get into a situation where it's possible to create invalid combinations:

  message Filter {
    string type = 1;
    Tags tags = 2;
    IPRange ipRange = 3;
  }

Now you can accidentally end up with code like this:

  f = Filter{}
  f.Type = FilterType_Tags
  f.IPRange = IPRange{}

or:

  if f.Type == FilterType_Tags {
    useFilter(f.IPRange)
  }

Re: Gunk: Modern front end and syntax for Protocol Buffers

Re: Gunk: Modern front end and syntax for Protocol Buffers