Support for proto2 syntax?
Opened this issue · 10 comments
I have an existing set of pb files that I'd be interested in using with elm, but they're written with proto2, and it looks like migrating to proto3 might require changes to the code interacting with them. Is there a chance we can support proto2 for this?
Hi Gavin, I'm actually making some changes to the code generation that should make it easier to support proto2 syntax, at least in principle. The main issue is that proto2 does not have a canonical JSON representation AFAICT (though I might have missed it), so so things like unset vs default fields and default enum values are slightly more vague there. Having worked with both proto2 and proto3, I came to appreciate proto3 simplicity and streamlined semantics, so I would personally advise you to consider migrating to proto3 for your projectsi at all possible. If your project is open source, feel free to post a link so i may take a look perhaps
It is in fact! It's Cockatrice. The proto files are here
Thanks, interesting project! I see you use quite advanced features such as extensions, which I would realistically not expect to ever support in this library to be honest. In proto3, you would have to use the Any type to achieve something similar, but on the other hand if you don't really expect other clients to extend your photos, you may as well inline them as regular fields in the base message. That's really up to you though, even if you did switch to use proto3, I still don't have a concrete plan on how to support it in elm in an idiomatic way. Suggestions are welcome though :)
I expect some nested ADTs would need to be generated, like type AllMessages = TypeOne | TypeTwo, type TypeOne = TypeOneA | TypeOneB, and so on.
so so things like unset vs default fields and default enum values are slightly more vague there
I'm looking for proto2 support because the way proto3 treats defaults, i.e., you cannot tell a value is unset of it happens to be set to the default value, this basically makes Maybe a useless, I think the one who designed proto3 designed it this way because he don't use ADT a lot, and they, those who use imperative languages, have null problems, so they think they can get away with a default value.
Maybe we can add some additional markers, like int32 a = 1 [optional = true], then the generated elm type for this filed would be a : Maybe Int.
@qwfy you can use well known types such as IntValue for that, and they should be translated into the corresponding Maybe type in elm. Let me know if you have any issue with that.
I am currently using this, the problem with the so called well known types (well known for what? amending a bad design?) is that they are not well supported, I have to manually box/unbox it on the other side.
Maybe instead of supporting a broken design, we support something better.
All said, I do appreciate your work.
I think "well known" refers to the fact that the proto compiler may treat them specially (which my elm implementation does). What language are you using on the other side? It seems like a possible fix would be to support such special implementation there too. Would that be reasonable?
The other side is OCaml, and the compiler is ocaml-protoc (it's a standalone compiler, not a plugin to the protoc binary).
If the biggest issue with supporting proto2 syntax is JSON representation, I may be able to help. The canonical protoc plugin for Scala was developed at my company and we reuse it very extensively ( binary format within the backed, and JSON between backend and frontend ). I'd love to work with you to develop the appropriate semantics. It's really not that different at all from proto3 semantics.