Type name clashes will always happen, and the more classes/interfaces .NET
will get, the more this will happen. For example the lovely 'Expression'
class in System.Linq.Expressions is a nice example of how things will
eventually become a problem due to name clashes.
The solution is simply re-alias the name in the file where the clash occurs
using a using statement. E.g. in my linq provider I use:
using LinqExpression = System.Linq.Expressions.Expression;
to avoid the name clash with my own 'Expression' class which has to be
referenced in that scope as well.
The problem becomes a real problem when existing code suddenly can't compile
because NHibernate gets an interface, as that will require that the existing
code is updated. However, you'll always run this risk, no matter where you
store the type, as the full namespace might be included through a using
statement at the top of the file, mitigating the fact the type is in some
special namespace.
TL;DR: it's not something one can fix nor will there be a solution to
prevent this problem in the future.
FB
> While I was updating one of my projects to NHibernate 3 alpha 2, I did
> notice that the ILogger interface is placed directly under the NHibernate
> root namespace. Although I think that the abstraction is a good thing,
it's
> too exposed and conflicts with any other ILogger (Castle's one for
example)
> out there.
>
> That been said, I want to know if it's possible to move it to a more
> internal namespace, like NHibernate.Logging or something like that. If the
> asnwer is yes, I'll be happy to provide a patch for that.
>
> Cheers,
> Henry Conceição
