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 there. 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 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 -~----------~----~----~----~------~----~------~--~---
