5 ms·

Could you expand on the problems you encountered?

colanderman 10y ago
I've never looked at proto3, but proto2 has at least the following issues: * No clue about namespacing. If you pick the wrong name for something, you can have name clashes within a protobuf, across uninterpreted option classes, with protobuf source code, with your own source code; and it's different if you're in Python or C. Nowhere are naming restrictions defined. * The API is maddening and inconsistent, especially in Python. (It's totally different between Python and C.) Some things look like lists but really aren't (e.g. you can't assign a list to a repeated field in Python). Even basic reflection (e.g. to get at uninterpreted options) is a Lovecraftian nightmare, and the docs are wholly unhelpful. * Good luck serializing a list. There's not really such a thing, despite that the API pretends like there is; there are only repeated fields. So you need a separate flag to distinguish "empty list" from "not present list". * Abstruse implementation. There are so many layers of indirection in the generated source and the core library that I wouldn't know where to start debugging. Not sure if they fixed any of these issues with proto3.
- cbsmith 10y ago
  The short answer is the Python implementation wasn't exactly great.
  - colanderman 10y ago
    Reflection in the C++ version is as bad or worse given that you can't mess around with it in a REPL to figure out how it really works. And the C++ version has most of the namespacing issues (e.g. any field starting with "set_" has potential to clash with another field). Both implementations are equally bad, despite that they seem to have been written by two separate teams that didn't communicate with each other.
    - cbsmith 10y ago
      Honestly, I never had much trouble with the C++ one.
- deleted 10y ago
  [deleted]
mattiemass 10y ago
Dealing with forward- and backwards-compatibility with enum changes has bit me many times in the past. So has required fields.

I've never looked at proto3, but proto2 has at least the following issues: * No clue about namespacing. If you pick the wrong name for something, you can have name clashes within a protobuf, across uninterpreted option classes, with protobuf source code, with your own source code; and it's different if you're in Python or C. Nowhere are naming restrictions defined. * The API is maddening and inconsistent, especially in Python. (It's totally different between Python and C.) Some things look like lists but really aren't (e.g. you can't assign a list to a repeated field in Python). Even basic reflection (e.g. to get at uninterpreted options) is a Lovecraftian nightmare, and the docs are wholly unhelpful. * Good luck serializing a list. There's not really such a thing, despite that the API pretends like there is; there are only repeated fields. So you need a separate flag to distinguish "empty list" from "not present list". * Abstruse implementation. There are so many layers of indirection in the generated source and the core library that I wouldn't know where to start debugging. Not sure if they fixed any of these issues with proto3.

cbsmith 10y ago
The short answer is the Python implementation wasn't exactly great.
- colanderman 10y ago
  Reflection in the C++ version is as bad or worse given that you can't mess around with it in a REPL to figure out how it really works. And the C++ version has most of the namespacing issues (e.g. any field starting with "set_" has potential to clash with another field). Both implementations are equally bad, despite that they seem to have been written by two separate teams that didn't communicate with each other.
  - cbsmith 10y ago
    Honestly, I never had much trouble with the C++ one.
deleted 10y ago
[deleted]

mattiemass 10y ago

Dealing with forward- and backwards-compatibility with enum changes has bit me many times in the past. So has required fields.