Kenton Varda wrote: > I'll be updating the documentation to explain this better soon. It's > a bit complicated. Check out unittest_custom_options.proto for an > example. Let me try to explain briefly... >
The unittest_custom_options.proto is useful. It certainly helps show the constraints at work. The design rationale I infer is that normal field names, unlike extensions, will never need to be qualified so there is no need for parenthesis around these names. This is promoted to a hard rule that normal field names are never allowed to be in parenthesis. Thus the parenthesis are present if and only if the thing named is an extension field. Since every single existing normal field name of an option message is NOT a message/group type, the first name part being unparenthesized means that there will be no '.' and no additional name parts. I have updated my Lexer and Parser (in my development version) to recognize the new proto file syntax and fill in the UninterpretedOption fields. This has been tested on unittest_custom_options.proto. No further processing of the new options is done yet: no name resolution, no conversion to extension field value. This will eventually get done. The normal field names are cooked into the Parser as in the previous version. Once the extensions bits are finished I might go back and bootstrap these so they are both more reflective and able to handle message/group types (even though none currently exist). Cheers, Chris --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. 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 -~----------~----~----~----~------~----~------~--~---
