In my experience, it seems easier to have too many namespaces than it is to
have too few. My instinct is to start with geode:: and Geode. and further
subdivide when it becomes unwieldy and collisions arise.
Sarge
> On 16 Jan, 2017, at 21:10, 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
