You don't have to worry about the uninterpreted_option field.  It's an
internal implementation detail of the parser.  You should pretend it isn't
The comment is saying that the uninterpreted_option field must have the name
"uninterpreted_option" in all *Options messages because the parser uses
reflection to access it.

On Wed, Nov 12, 2008 at 2:47 AM, Jon Skeet <[EMAIL PROTECTED]> wrote:

> I was just looking over descriptor.proto for the option extensions,
> and I spotted this comment that I hadn't seen before:
> // Clients may define custom options as extensions of the *Options
> messages.
> // These extensions may not yet be known at parsing time, so the
> parser cannot
> // store the values in them.  Instead it stores them in a field in the
> *Options
> // message called uninterpreted_option. This field must have the same
> name
> // across all *Options messages. We then use this field to populate
> the
> // extensions when we build a descriptor, at which point all protos
> have been
> // parsed and so all extensions are known.
> I don't understand the "This field must have the same name across all
> *Options messages." Am I right in saying that's an implementation
> detail about the uninterpreted_option field? It's not saying that the
> extensions themselves need to have the same name across all *Options
> messages, right?
> Just thought it would be worth clarifying before I do the wrong
> thing :)
> >

You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at

Reply via email to