Alex: Thanks for pointing me to the right place on import paths, next time I'll RTFM ;-)
Enum Values are supported, but *Enum Value* *Options *are not... at least as far as i can tell. (I'll have to check more closely tomorrow) As far as supporting custom options goes, I have some experience in that front as I had to support them for what I was doing. They were by far the hardest part to build into the grammar and I never quite got it working right. The best I managed was to have five separate sets of rules, one for each type of custom option (field, enum, enum value, message, file)... I've attached what I came up with for an XText grammar in case it gives you any ideas on how to better handle it. The two things I never quite settled were: 1) How to handle enumation namespaces between enum value declarations and usage of those values in custom options. The namespace in proto is global, but XText grammar expects the ID to be qualified when used in another scope (while the compiler does not)... I suspect I just don't have a good enough grasp of XText to solve that problem. To support enumeration values i ended up putting the enum values at the top level by not having them be part of the the enum production. 2) How to validate the *values *of custom options... I left this as simply either a "MessageOption" or a "DirectOption", where the Message option is constrained to the structure (but not valid contents) of a TextFormat protocol buffer, and the Direct option is any of int, float, ID, etc... This could be taken further to handle each unique syntax type separately but it seems very inelegant and I was hoping to figure out something better before releasing anything (which I won't with now anyway as this is clearly the project that should move forward). One possibility that i was leaning towards that could solve both of these problems was to allow validation of option fields to fall on the compiler itself... The XText API allows for secondary validation to occur, and the compiler provides line and character numbers in it's output... presumably you could just run the exe through java and capture & parse the System.out stream to determine any syntax errors not caught directly by the grammar. I did not have the compiler integrated but these plugins do - so it would seem this might not be that difficult to pull in. The downside of this option being that it will not provide auto-complete or other built in features of XText automatically - although to some extent that could be made up for with more custom code. -Ben Wright -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To view this discussion on the web visit https://groups.google.com/d/msg/protobuf/-/xApESYTqNVoJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
Protobuf.xtext
Description: Binary data
