On Fri, Jan 31, 2014 at 4:36 AM, <proto...@googlecode.com> wrote: > > Comment #7 on issue 515 by peterhan...@yahoo.com: More intelligent enums > http://code.google.com/p/protobuf/issues/detail?id=515 > > The proposed solution doesn't work because: >>> 1. The name of the enum type is changed from "Foo" to "Foo::Enum" which >>> will be confusing to the users. >>> >> > The proposal text says the new option is .. well, optional. So if you > don't specify it protobuf compiler will (regardless of target language) > generate exactly same code as today. How can that be confusing ? .. except > for those who explicitly put in the new proposed option in the .proto file > .. but then those people have made a conscious choice to use the new > proposed feature.
When enabling this option, the enum type will be named as Foo::Enum while normal people will expect it to be Foo (and indeed it's Foo in any other language). This is the kind of inconsistency we should avoid. > > > 2. For enums nested in a message you simply can't nest a namespace in a >>> class. >>> >> > Not sure I understand. > > In any case, if you really believe so, we could say in the documentation > that the proposed new option has no effect for C++ and make sure that's > what is happening. This would still bring great benefits to anyone else > (most languages has the notion of namespace for enums) just not to C++ > users. > > There are already options in .proto files that only benefit some languages > but not others so going down that route is not something new. It all > depends if the design idea of protobuf is to be bound by the lowest common > denominator, in this case C++ ? I certainly understand and appreciate the > desire to keep protobuf design lean and mean so I would sympathize > (somewhat reluctantly :-)) with such a conscious choice. > > > the value of allowing duplicated enum value names is also very limited. >>> It doesn't seem to be a worthwhile effort to me. >>> >> > What? Perhaps we're just different but we run into these issues all the > time in particular with enum values such as "YES", "NO", "NONE, > "UNDEFINED", words that are likely to be used in different enums. Yes, > there are ways around it .. but they just make protobuf code harder to read > and make your setup more convoluted than what it needs to. And I love > protobuf for the exact opposite reasons. > C++ has such a limitation for many years and we live with it very well. There are well established coding styles requiring a prefix to enum values. I honestly don't believe it makes the code harder to read. > > Cheers. > > > > > -- > You received this message because this project is configured to send all > issue notifications to this address. > You may adjust your notification preferences at: > https://code.google.com/hosting/settings > > -- > 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. > -- 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.
