+1 for Apache.Geode.Client ( .net ) and apache::geode::client( C++ ) Thanks Avinash
On Wed, Jan 18, 2017 at 3:17 AM, Jacob Barrett <jbarr...@pivotal.io> wrote: > Anthony, > > You make a good argument. Have fun converting all those namespaces for us > in your free time. :) > > Apache.Geode.Client and apache::geode::client it is then... > > Anyone else want to chime in before we execute on this? > > -Jake > > > > On Tue, Jan 17, 2017 at 7:39 AM Anthony Baker <aba...@pivotal.io> wrote: > > > Based on [1] [2] [3] it seems like the .NET convention would be: > > > > Apache.Geode.Client > > > > For cpp the conventions seem a lot more muddled [4] [5]. Even for Apache > > projects [6] [7] [8] [9] there’s lots of variation. This variant looks > > good to me: > > > > apache::geode::client > > > > but I could be convinced otherwise. > > > > Anthony > > > > [1] https://msdn.microsoft.com/en-us/library/ms229026(v=vs.110).aspx > > [2] https://msdn.microsoft.com/en-us/library/893ke618(v=vs.71).aspx > > [3] http://stackoverflow.com/questions/918894/namespace- > naming-conventions > > [4] https://google.github.io/styleguide/cppguide.html#Namespace_Names > > [5] https://wiki.openstack.org/wiki/CppCodingStandards#Namespace_Names > > [6] https://thrift.apache.org/tutorial/cpp > > [7] http://avro.apache.org/docs/1.6.1/api/cpp/html/namespaces.html > > [8] > > http://stackoverflow.com/questions/8765473/compiling-a- > c-program-using-thrift-and-cassandra > > [9] https://www.gridgain.com/sdk/1.7.2/cppdoc/namespaces.html > > > > > > > On Jan 16, 2017, at 9:10 PM, Jacob Barrett <jbarr...@pivotal.io> > wrote: > > > > > > An upcoming change we need to decide on is the C++ and .NET namespace > for > > > the C++ and .NET clients. > > > > > > *C++* > > > Current: > > > *::gemfire* > > > Thoughts: > > > *::apache::geode::client* > > > *::geode::client* > > > I shy away from prefixing with *apache* since it requires extra blocks > in > > > C++: > > > (formatted to Google C++ style guide) > > > namespace apache { > > > namespace geode { > > > namespace client { > > > class Cache {...}; > > > } // namespace client > > > } // namespace geode > > > } // namespace apache > > > vs. > > > namespace geode { > > > namespace client { > > > class Cache {...}; > > > } // namespace client > > > } // namespace geode > > > vs. > > > namespace geode { > > > class Cache {...}; > > > } // namespace geode > > > > > > I shy away form just *geode* because it feels too short but I am not > that > > > opposed to it. The question is would we likely have anything else in > C++ > > > under the *geode* namespace that is not the client? > > > > > > *.NET* > > > Current: > > > *GemStone.GemFire.Cache.Generic* > > > Thoughts: > > > *Apache.Geode.Client* > > > *Geode.Client* > > > I am not a fan of *Apache.Geode.Cache.Generic* because *Generic* is > > legacy > > > form the replacement of the non-generic versions of the API and *Cache* > > > feels redundant. Feels odd to be working with > > *Apache.Geode.Cache*.*Cache* > > > objects. > > > The same issues with the C++ namespaces apply here since our .NET > client > > is > > > currently C++/CLI which suffers the same namespace block issues. > > > > > > It would feel good to have the namespaces be somewhat consistent > between > > > clients but it is not normal for namespaces in C++ or .NET to use the > > > reverse domain style that Java uses. So *org::apache::geode::client / > > > Org.Apache.Geode.Client* or some variant is off the table I think. > > > > > > Anyone have other thoughts? > > > > > > Thanks, > > > Jake > > > > >
