search

bchavez / RethinkDb.Driver

:headphones: A NoSQL C#/.NET RethinkDB database driver with 100% ReQL API coverage.
http://rethinkdb.com/api/java
Other
384 stars 134 forks source link

Community Vote: RethinkDb or RethinkDB namespace #72

Closed bchavez closed 8 years ago

bchavez commented 8 years ago

@epsitec proposed the following change: I'm slowly getting up to speed with RethinkDb.Driver and one tiny little detail just does not feel right: the naming convention used. Is "DB" a two-letter acronym which should be written "DB" or should ""DB" in the context of the "RethinkDB" product name be treated differently?

See for instance RethinkDb.Driver.RethinkDB.R where once it is written with Db (namespace) and once with DB (class name). Is this ​an accident​ or was this a design decision?

I would be more comfortable with the RethinkDB casing everywhere. But can you afford to make such a breaking change ​for naming aesthetics​ only?

@bchavez response: It was kinda both. I checked the .NET framework design guidelines ​and​ the actual implementation in .NET. What I found was, there are actual namespaces with System.Data.OleDb and types named OleDbFactory/IDbConnection/SqlDbType/DbCommand. To make matters worse, there are types in System.Data like DBNull. LoL. Now, the guidelines are pretty explicit about 2 letter acronyms and things that are commonly well known like ​input-output​ be named like System.IO both caps... If MS carried out the same for System.Data ​i think​ IDbCommand would be named IDBCommand and System.Data.OleDb would be System.Data.OleDB. Who knows. I really don't know. There are also guidelines for namespaces, specifically SS3.4 Names of Namespaces in ​Framework Design Guidelines​ where RethinkDB is company and product name that states <Company>.<Product|Technology>. But then there's that grey area where I am not officially associated with RethinkDB​ the company even though I use their logo on NuGet and we have a cool thinker banner in our GitHub repo. Overall, though, to me personally, I could go with either naming convention. Six of one, half-dozen the other. You can submit a GitHub issue and put it up for a community vote. The people on the repository watch list are among the most passionate devs concerned with the direction of the driver. So, whatever naming convention wins out; I'm fine with. And the intentional bit was that RethinkDB was intentionally different from RethinkDb the namespace so that if you were doing some crazy .NET/CLR reflection type loading you could just match on RethinkDB find the fully qualified name to the root RethinkDB object in the RethinkDb namespace. (Also, RethinkDB is the same type name as the Java Driver's RethinkDB).

So, let's put it up for a community vote to change the root RethinkDb namespace ....

:+1: for RethinkDB.Driver :-1: for RethinkDb.Driver and leave as is.

This would be a breaking change, but easy enough to resolve.

Also, some additional community packages based on the RethinkDb.Driver are now starting to pop up on NuGet using RethinkDB capitalization like Nancy.Session.RethinkDB. https://www.nuget.org/packages?q=rethinkdb Just food for thought.

oliverjanik commented 8 years ago

I think the IO thing was a mistake and a dent in consistency and brings up the problem with defining "well-known" acronyms. RethinkDb all the way.

epsitec commented 8 years ago

I'd vote for RethinkDb all the way too (get rid of RethinkDB class).

By promoting R from being a static (singleton) property of class RethinkDB to a static class we could rewrite our code like this:

using  RethinkDb.Driver;
...
// RethinkDB.R.Db("foo").Table("bar")...
R.Db("foo").Table("bar")...

and so we no longer have to deal with RethinkDB (the class) having another name than RethinkDb (the namespace) for disambiguation.

I haven't looked into TopLevel however to see if it is at all possible to convert it to a static class.

bchavez commented 8 years ago

Hey there,

It looks like the community is pretty set on RethinkDb. An informal poll on the .NET slack group confirms this too... so, I think we'll keep everything the way it is for now.

Someone on the .NET slack group mentioned Db capitalization makes sense when used in context as a general concept (as it's been used in the .NET Framework, ex DBNull); however, RethinkDB is an official company name and product. Ultimately, the company name/product should take precedent. After some idle thought on the subject, I kinda feel in agreement that RethinkDB should take precedent and be used as the official namespace per SS 3.4 Names of Namespaces in ​Framework Design Guidelines <Company>.<Product|Technology>/RethinkDB.Driver.

If the C# driver ever makes it to official status, the company name should probably be used as the official namespace. So, we'll defer this discussion, if-when RethinkDB officially joins the .NET party :balloon:. It would be a breaking change, but a clean break from community to official status.

RE: Static R

I have some reservations about promoting R to a static class. My first concern would be, it would be a break from Java. At the moment we rely on and benefit heavily from Java's API documentation, samples, and Unit Tests. It would add additional maintenance for me internally when porting upstream changes from Java. Currently, it is a delicate balance maintaining a high quality driver with minimal maintenance effort.

Secondly, and probably more importantly, promoting R to static class away from static instance would remove the ability to use C# Extension Methods at TopLevel which could be useful in some cases to tee off custom AST queries. Users can extend the entire C# AST API, including TopLevel, without having to recompile from source. I think that's a cool win.

IE: R.Table<Foo>()

Thanks everyone for your inputs and feedback. I really appreciate it.

:v: :okhand:[**"We can, we can, we can, we can work it out... Even if we try and it all burns down..."**_](https://www.youtube.com/watch?v=AyA8EQxVGwY)