Hi Ben, I'll take a look at your grammar. Many thanks!
I'd suggest to move any conversations regarding the new Eclipse plug-in to its own mailing list: http://groups.google.com/group/protobuf-dt . This way we don't spam non-Eclipse users :) Cheers, -Alex On Wed, Aug 3, 2011 at 4:15 PM, Benjamin Wright <compuware...@gmail.com> wrote: > 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 protobuf@googlegroups.com. > To unsubscribe from this group, send email to > protobuf+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/protobuf?hl=en. > -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
