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
I don't like the idea of having a namespace containing a single
ILogger type...
On Sep 18, 11:30 pm, Tuna Toksoz <tehl...@gmail.com> wrote:
> Even if the cause is somehow remediable in other way, the solution is
> reasonable. moving it to Diagnostics/Logging/Logger wouldn't hurt and is a
> good idea.
>
> Tuna Toksöz
> Eternal sunshine of the open source mind.
>
>
>
>
> On Sat, Sep 18, 2010 at 11:28 AM, Roelof Blom <roelof.b...@gmail.com> wrote:
> > Exactly the constructive answer you'd expect these days from NH's lead.
>
> > So, what about it? The request is trivial, and Henry will supply a patch.
>
> > -- Roelof
>
> > Op 18 sep. 2010 om 17:15 heeft Fabio Maulo <fabioma...@gmail.com> het
> > volgende geschreven:
>
> > Perhaps I should send the same request to Microsoft .NET team because they
> > have used ISet.
>
> > On Sat, Sep 18, 2010 at 9:39 AM, Johannes Gustafsson <<johanne...@gmail.com>
> > johanne...@gmail.com> wrote:
>
> >> +1
>
> >> I have the same problem where it conflicts with our own ILogger interface.
> >> I guess NHibernate.ILogger should not be used outside NH anyway (except for
> >> contrib and NHibernate.* libs) so hiding it in a deeper namespace is a good
> >> idea IMHO.
>
> >> /Johannes
>
> >> 2010/9/18 Henry Conceição < <henry.concei...@gmail.com>
> >> henry.concei...@gmail.com>
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
You did not explicitly say something about Henry's proposal, no. But implicitly, to me at least, you did with the ISet remark. I apoligize if my response came out rude.
Well, you're right about that Fabio, though I guess I would hate it if
eventually I had to have "using System.Collections.Generic.Sets"
besides the S.C.G "everywhere", since it seems reasonable to believe
that the MS ISet will eventually become the more widespread class.
IMHO of course.
But we are open source, and in general more open and willing to listen
than MS often appears, and have therefore excellent abilities to
actually implement the rational solution. :)
Personally I like the idea of putting classes and interfaces that are
most of the time only used internally by NH or by a specific extension
implementation in a sub-namespace, so the main namespace is cleaner.
/Oskar
I've created a ticket, containing the patch:
http://216.121.112.228/browse/NH-2337
Cheers,
Henry Conceição
Since logging and data access usually share the same space inside a
model, the new interface introduced by NHibernate causes a lot of
friction: the developer must open each class that consumes the logger
service and something from NHibernate and fix his namespace using
directives.
Cheers,
Henry Conceição
The issue isn't related with Windsor. The issue is that the ILogger
abstraction is the most obvious one, and any
project/application/framework that tries to decouple/abstract it's
logging machinery ends up using it.
If you're doing it for the sake of the relations between Castle and
NHibernate, you're doing it for the wrong reasons. The ILogger
abstraction is so obvious that NHibernate stick with it. The other
option (ILog) is normally used by the logging frameworks itself...
surprises me that you didn't realized it.
But if you really thinks that an ORM should leak his internal logging
stuff all over place, demanding it users to change their classes,
you're a more limited leader than I thought.
PS: A youtube song? Really? Even for you, it's was ridiculous.
Cheers,
Henry Conceição
Cheers,
Henry Conceição
An incestuous one?
Google Suggest
Tks a lot for the renaming.
Cheers,
Henry Conceição