Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for proto2 syntax? #1

Open
Daenyth opened this issue May 22, 2016 · 10 comments
Open

Support for proto2 syntax? #1

Daenyth opened this issue May 22, 2016 · 10 comments

Comments

@Daenyth
Copy link

Daenyth commented May 22, 2016

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?

@tiziano88
Copy link
Owner

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

@Daenyth
Copy link
Author

Daenyth commented May 22, 2016

It is in fact! It's Cockatrice. The proto files are here

@tiziano88
Copy link
Owner

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 :)

@Daenyth
Copy link
Author

Daenyth commented May 22, 2016

I expect some nested ADTs would need to be generated, like type AllMessages = TypeOne | TypeTwo, type TypeOne = TypeOneA | TypeOneB, and so on.

@qwfy
Copy link

qwfy commented Jul 29, 2017

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.

@tiziano88
Copy link
Owner

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

@qwfy
Copy link

qwfy commented Aug 1, 2017

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.

@tiziano88
Copy link
Owner

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?

@qwfy
Copy link

qwfy commented Aug 2, 2017

The other side is OCaml, and the compiler is ocaml-protoc (it's a standalone compiler, not a plugin to the protoc binary).

@gamebox
Copy link

gamebox commented Aug 26, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants