Closed damianh closed 11 years ago
Agreed.
Ok, I wasn't sure on that, but I think it has merit. It will keep people's namespace imports simpler anyway. I forget not everyone likes ReSharper. :)
Actually, I'm not sure that I agree for the Tests project. Raven's own test project uses the Raven.Tests namespace, and I know that various test runners have the option to group tests by namespace. It would probably be best to separate the contrib tests from the others. Yes?
Changed for Raven.Client. Others can update their own areas if desired. It makes sense for client extensions, but I'm not sure it makes sense for other bits.
Ok, that's fine. The tests project is no biggie - Client one is more important.
Send a PR ( Issue #8 ) with proposed new organisation.
looks good. will merge.
Awesome, thx :)
:thumbsup:
Raven.Client.Contrib should have it's default namespace as "Raven.Client" as that is the namespace it is extending. Thus when a user adds a reference to Raven.Client.Contrib package they will see the extensions in their intellisense without having to add a 'using Raven.Client.Contrib" directive.
The *Extensions types should be in matching namespaces that they extend. For instance, DocumentExtensions should be in a Connection folder and thus have namespace "Raven.Client.Connection". Again this helps discovery in intellisense.
Raven.Client.Contrib.Tests project default namespace should be Raven.Client (unit test classes don't have to be in a "Tests" namespace...)