title: solutions to resolve enum field naming restriction in Google protobuf due to C++
body: <p>As you might know, when you define enums in Google protobuf either with global scope or in same message, you can't define enum field name to be same if enums are sibling.</p>
  
  <p>Even if you are going to generate Java code with proto file, protoc complains about it and doens't generate any code with following message.</p>
  
  <pre><code>"XXX" is already defined in "your.package.name".
  Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type,
  not children of it. 
  Therefore, "XXX" must be unique within "your.package.name", not just within "your_enum_name".
  </code></pre>
  
  <p>so, which means you should do something like</p>
  
  <ol>
  <li>wrapping the colliding enums with message.
  <ul>
  <li>Pros : well... protoc doesn't fail?</li>
  <li>Cons : generate code is going to have one extra static wrapper class so that it will increase SerDes cost a little bit + naming seems long enough. e.g, CURRENCY.NAMESPACE(wrapper message name).USD</li>
  </ul></li>
  </ol>
  
  <p>or</p>
  
  <ol start="2">
  <li>use prefix for the field, so if your conflicting field name is UNKNOWN and it's in CURRENCY, it's going to be CURRENCY.CURRENCY_UNKNOWN or something like that.
  <ul>
  <li>Pros : simple</li>
  <li>Cons : as ugly as #1, inconsistency with existing enum field naming that doesn't have any prefix.</li>
  </ul></li>
  </ol>
  
  <p>or</p>
  
  <ol start="3">
  <li>Just don't use Enum. Use string type.
  <ul>
  <li>Pros : simple, don't need to define fallback enum field like UNKNOWN = 1 as default.</li>
  <li>Cons : losing benefit of having enum.</li>
  </ul></li>
  </ol>
  
  <p>Seems like C++ 11 supports better enums that doesn't have this issue, but unfortunately latest protoc doesn't support it, and we can't simply ask other consumers to switch their side to use C++ if they are not using it.</p>
  
  <p>So, it's going to be choosing less worse solution rather than best solution, and probably we are going to use #2 at this point. Does anyone have same experience and tell me what was your solution and how is it ended up?</p>