On Mon, Oct 6, 2008 at 10:36 AM, Chris <[EMAIL PROTECTED]> wrote: > 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.
Mostly right. The way I think of it, what the parentheses do is change the name lookup semantics of the field. An unparenthesized identifier names a field defined within the scope of the message type, whereas a parenthesized expression names something relative to the *current* scope. These theoretical details aren't terribly important, though. > 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. Currently, that's true. However, if someone added a message- or group-type field to one of the options protos, the current code would be able to handle it automatically. The syntax would be like: optional int32 foo = 1 [some_message_option.some_field = 123]; > 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. OK. Note that users should never be playing with UninterpretedOptions, though. So, until the actual conversion to extensions happens, I would call the feature incomplete. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
