[protobuf] Re: Enum values are siblings of their type, not children of it.

2016-01-02 Thread GoldenBull Chen

https://github.com/google/protobuf/issues/1079

在 2010年8月21日星期六 UTC+8上午2:12:30,alopecoid写道:
>
> 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 unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.


[protobuf] Re: Enum values are siblings of their type, not children of it.

2015-12-28 Thread GoldenBull Chen
Agree. It's a bad design to use old C++ scoping rules for enum values. Even 
C++ itself has introduced enum class in C++11.

在 2015年11月10日星期二 UTC+8上午3:15:35,Teddy Zhang写道:
>
> Sorry to dig this old thread.
> I now one of the solution right now is to put the enum to different proto 
> file and put them into different package. But that doesn't really work if 
> the enums are under the same message.
>
> I would suggest add an option for c/c++, like below:
> enum Foo { 
>   option c_enum_prefix = "eFoo";
>   FIRST = 0; 
>   SECOND = 1; 
>   BOTH = 2; 
> } 
>
> And it will generate enum like below in c/c++:
> enum Foo {
> eFooFIRST = 0,
> eFooSECOND = 1,
> eFooBOTH = 2
> };
>
> This won't affect enum generation in managed language like java/c#, and it 
> won't break backward compatibility (if the option is not specified, 
> fallback to old behavior).
>
> Any comments?
>
> On Friday, August 20, 2010 at 11:12:30 AM UTC-7, alopecoid 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 unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.


[protobuf] Re: Enum values are siblings of their type, not children of it.

2015-11-09 Thread Teddy Zhang
Sorry to dig this old thread.
I now one of the solution right now is to put the enum to different proto 
file and put them into different package. But that doesn't really work if 
the enums are under the same message.

I would suggest add an option for c/c++, like below:
enum Foo { 
  option c_enum_prefix = "eFoo";
  FIRST = 0; 
  SECOND = 1; 
  BOTH = 2; 
} 

And it will generate enum like below in c/c++:
enum Foo {
eFooFIRST = 0,
eFooSECOND = 1,
eFooBOTH = 2
};

This won't affect enum generation in managed language like java/c#, and it 
won't break backward compatibility (if the option is not specified, 
fallback to old behavior).

Any comments?

On Friday, August 20, 2010 at 11:12:30 AM UTC-7, alopecoid 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 unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.


[protobuf] Re: Enum values are siblings of their type, not children of it.

2014-11-17 Thread WonHee Jung
I don't think it's added in 2.4.1+. I don't see any related changes in 
changelog.

On Friday, November 1, 2013 12:45:03 PM UTC-7, greg.mal...@gmail.com wrote:

 The solution is available in the latest version??? Please elaborate. I'm 
 using 2.5.0 and I don't see it.

 -Greg

 On Tuesday, May 28, 2013 11:12:46 PM UTC-4, Giri Guntipalli wrote:

 Hi enum values conflict for C++ is there any solution now solution 
 suggested below is available in latest version any workarounds to handle 
 this problem with 2.4.1 or latert versions.
  
 Giri
 On Friday, 20 August 2010 23:42:30 UTC+5:30, alopecoid 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 unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.


[protobuf] Re: Enum values are siblings of their type, not children of it.

2013-11-01 Thread greg . malatestinic
The solution is available in the latest version??? Please elaborate. I'm 
using 2.5.0 and I don't see it.

-Greg

On Tuesday, May 28, 2013 11:12:46 PM UTC-4, Giri Guntipalli wrote:

 Hi enum values conflict for C++ is there any solution now solution 
 suggested below is available in latest version any workarounds to handle 
 this problem with 2.4.1 or latert versions.
  
 Giri
 On Friday, 20 August 2010 23:42:30 UTC+5:30, alopecoid 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 unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/groups/opt_out.


[protobuf] Re: Enum values are siblings of their type, not children of it.

2013-05-28 Thread Giri Guntipalli
Hi enum values conflict for C++ is there any solution now solution 
suggested below is available in latest version any workarounds to handle 
this problem with 2.4.1 or latert versions.
 
Giri
On Friday, 20 August 2010 23:42:30 UTC+5:30, alopecoid 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 unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.




[protobuf] Re: Enum values are siblings of their type, not children of it.

2012-07-24 Thread Alex Foygel
Another option is to use C++11 scoped enum syntax:

enum class Foo {
 FIRST = 0;
 SECOND=1;
}
and then generate scoped enums, which would look exactly like the snippet 
above.

On Friday, August 20, 2010 1:12:30 PM UTC-5, alopecoid 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 view this discussion on the web visit 
https://groups.google.com/d/msg/protobuf/-/KAnQDJtUWJcJ.
To post to this group, send email to protobuf@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.