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 protobuf@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to