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
> // 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
> // message called uninterpreted_option. This field must have the same
> // across all *Options messages. We then use this field to populate
> // 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 firstname.lastname@example.org
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at