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
