You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Jacob Barrett <jb...@pivotal.io> on 2017/01/17 05:10:02 UTC
Native Namespace
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
Re: Native Namespace
Posted by Avinash Dongre <ad...@apache.org>.
+1 for Apache.Geode.Client ( .net ) and apache::geode::client( C++ )
Thanks
Avinash
On Wed, Jan 18, 2017 at 3:17 AM, Jacob Barrett <jb...@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 <ab...@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 <jb...@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
> >
> >
>
Re: Native Namespace
Posted by Jacob Barrett <jb...@pivotal.io>.
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 <ab...@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 <jb...@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
>
>
Re: Native Namespace
Posted by Anthony Baker <ab...@pivotal.io>.
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 <jb...@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
Re: Native Namespace
Posted by Michael William Dodge <md...@pivotal.io>.
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 <jb...@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