It could be made an option. Something like...
message MyMessage {
enum Foo {
option cpp_namespace = true;
FIRST = 0;
...
}
...
}
...and then could be made the default if there is ever a Proto3.
But, even if this is just ends up on some "if-there-ever-is-a-Proto3"
to-do list, that would be cool... just so it's not forgotten about.
It's one of those small things that make the API nicer. I've come
across this scenario several times (and so have other colleagues).
On Tue, Aug 24, 2010 at 5:56 PM, Kenton Varda <ken...@google.com> wrote:
> How would you make this change without updating millions of lines of
> existing C++ code that uses protobuf enums?
>
> On Fri, Aug 20, 2010 at 11:12 AM, alopecoid <alopec...@gmail.com> wrote:
>>
>> Hi,
>>
>> This post is about the fact that protobuf enum values use C++ scoping
>> rules, meaning that, unlike in Java, enum values are siblings of their
>> type, not children of it.
>>
>> Say I have the following contrived message:
>>
>> message MyMessage {
>> enum Foo {
>> FIRST = 0;
>> SECOND = 1;
>> BOTH = 2;
>> }
>> required Foo foo = 1;
>>
>> enum Bar {
>> FIRST = 0;
>> SECOND = 1;
>> BOTH = 2;
>> }
>> required Bar bar = 2;
>> }
>>
>> This wouldn't compile because the protobuf compiler recognizes the
>> fact that for C++, the generated enum values for Foo and Bar would
>> conflict with each other.
>>
>> However, for Java, this wouldn't be a problem. I would like to propose
>> that instead of "punishing" the generated Java code because of C++'s
>> strange enum behavior (by forcing developers to rename their enum
>> values even though they don't collide), that instead, the generated C+
>> + enum declarations are wrapped in their own nested namespaces? For
>> example, something like:
>>
>> namespace Foo {
>> enum Enum {
>> FIRST = 0;
>> SECOND = 1;
>> BOTH = 2;
>> }
>> }
>>
>> namespace Bar {
>> enum Enum {
>> FIRST = 0;
>> SECOND = 1;
>> BOTH = 2;
>> }
>> }
>>
>> At this point, the enum values would be accessed like Foo::FIRST,
>> Bar::FIRST, etc, which would eliminate the enum value collision
>> problem altogether, and at the same time make them appear to behave
>> more like Java's enum scoping rules (which arguably make more sense).
>>
>> Thoughts?
>>
>> Thank you.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Protocol Buffers" group.
>> To post to this group, send email to proto...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> protobuf+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/protobuf?hl=en.
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
