ILogger Namespace

[Henry Conceição]

Hi,

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

[Johannes Gustafsson]

+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.c...@gmail.com>

[Fabio Maulo]

Perhaps I should send the same request to Microsoft .NET team because they have used ISet.

--
Fabio Maulo

[Roelof Blom]

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

[Tuna Toksoz]

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.

http://devlicio.us/blogs/tuna_toksoz
http://tunatoksoz.com
http://twitter.com/tehlike

[Fabio Maulo]

again another erudite.

I didn't say nothing about Henry proposal and you are saying something to me. Who you are ?

IMO there is no problem just because it is one minute fix, using Resharper, renaming the interface.

--
Fabio Maulo

[Stephen Bohlen]

Nor do I.  If we are to do this at all I would recommend at least a more general namespace (e.g., Diagnostics perhaps?) so that it can function more broadly as a category for future additional similar things rather than just a disambiguation prefix for ILogger.

Not sure just exactly what those other things would even be <g>, but at least they too won't need their own namespace if they arrive just b/c they don't logically fall under Nhibernate.Logger.*

Steve Bohlen
sbo...@gmail.com
http://blog.unhandled-exceptions.com
http://twitter.com/sbohlen

On Sat, Sep 18, 2010 at 11:33 AM, Julian <julian....@gmail.com> wrote:

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.
>

> http://devlicio.us/blogs/tuna_toksozhttp://tunatoksoz.comhttp://twitter.com/tehlike

>
>
>
> 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>

[Julian]

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.
>

> http://devlicio.us/blogs/tuna_toksozhttp://tunatoksoz.comhttp://twitter.com/tehlike

>
>
>
> 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>

[Julian]

That could be the way to go. I noticed that Logging.cs has 7 classes/
interfaces in it, so now might be a good time to create an appropriate
home for them. I was incorrectly assuming we were only talking about
one ILogger interface here. Don't know if this would be considered a
breaking change, or have any negative implications...

On Sep 18, 11:38 pm, Stephen Bohlen <sboh...@gmail.com> wrote:
> Nor do I.  If we are to do this at all I would recommend at least a more
> general namespace (e.g., Diagnostics perhaps?) so that it can function more
> broadly as a category for future additional similar things rather than just
> a disambiguation prefix for ILogger.
>
> Not sure just exactly what those other things would even be <g>, but at
> least they too won't need their own namespace if they arrive just b/c they
> don't logically fall under Nhibernate.Logger.*
>
> Steve Bohlen

> sboh...@gmail.comhttp://blog.unhandled-exceptions.comhttp://twitter.com/sbohlen

>
>
>
> On Sat, Sep 18, 2010 at 11:33 AM, Julian <julian.maug...@gmail.com> wrote:
> > 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.
>

> >http://devlicio.us/blogs/tuna_toksozhttp://tunatoksoz.comhttp://twitt...

[Fabio Maulo]

It will be a breaking change between NH3Alpha2 and NH3Aplha3.

Breaking changes will be at least for NHCH and another logging adapter published in codeplex (IIRC).

btw not a big problem.

--
Fabio Maulo

[Frans Bouma]

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

[Roelof Blom]

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.

Seems like the parallel conversation on twitter about this subject was meant as a more philosophical thing, although it had a strangely tone. Again, my perception perhaps.

Anyway, as ILogger exists in both NH and Castle.Core it's causing friction. As both frameworks are frequently used together we must and can resolve this. NH's variant being much younger and therefore suspected to cause much less breakage was the source of the request to move  it IMHO.

 

-- Roelof (a Castle project committer)

[Fabio Maulo]

Frans, the same happened with ISet and the matter is that we can't do anything about it than use what exactly you have mentioned, as already we are doing in NH's for Type.

btw in this case we can easy rename the ILogger interface to something like "INhLogger"; it isn't cool but I'm sure that nobody will have a conflict with it and for us it does not include the modification of all sources adding a new namespace (it will be a matter of one minute only).

--
Fabio Maulo

[Fabio Maulo]

On Sat, Sep 18, 2010 at 1:09 PM, Roelof Blom <roelo...@gmail.com> wrote:

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.

Apologize accepted.

--
Fabio Maulo

[Fabio Maulo]

This is the re-phrasing, of your phrase, about what I mean:

Anyway, as ISet exists in both NH and .NET4 it's causing friction. As both frameworks are frequently used together we must and can resolve this. .NET4's variant being much younger and therefore suspected to cause much less breakage was the source of the request to move  it IMHO.

--
Fabio Maulo

[Oskar Berggren]

2010/9/18 Fabio Maulo <fabio...@gmail.com>:

> This is the re-phrasing, of your phrase, about what I mean:
> Anyway, as ISet exists in both NH and .NET4 it's causing friction. As both
> frameworks are frequently used together we must and can resolve this.
> .NET4's variant being much younger and therefore suspected to cause much
> less breakage was the source of the request to move  it IMHO.

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

[Roelof Blom]

How insightful! You should put this on Connect.

-- Roelof

[Fabio Maulo]

Oskar,

The solution is not a problem.

The concept is the problem. What .NET gave us, as solution, is namespaces and probably for that reason MS team does not be to worry about the name of a class/interface.

Where I'm working with .NET4 and I need ISet of Iesi I have to specify the namespace using an alias or the full namespace of the class.

Personally I don't have any kind of problem with NH's ILogger in no one of the projects I'm involved in this moment, where I'll have a problem I'll use namespaces to disambiguate the interface/class name.

In this case we will do an exception only because Castle is our cousin... (even if some Castle's committers, not all only some, have not yet understood)

--
Fabio Maulo

[Henry Conceição]

Hi all,

I've created a ticket, containing the patch:
http://216.121.112.228/browse/NH-2337

Cheers,
Henry Conceição

[Johannes Gustafsson]

I believe that the comparison between .net:s ISet and NH:s ILogger is a bit unfair. 

ISet fills the gap of a missing container interface in the BCL, therefore a breaking change with Iesi:s ISet is reasonable.

NH:s ILogger is used for internal logging and has no use outside NH (I'm using NH for it's capabilities as an ORM, not for it's logging capabilities). 

Therefore, IMHO, I believe it should be either renamed or moved into another namespace.

Regards,

Johannes

2010/9/19 Henry Conceição <henry.c...@gmail.com>

[Jason Dentler]

The namespace-qualified name is NHibernate.ILogger. If anyone outside of NH has their own implementation, then shame on them. Otherwise, the solution is using statements. That's why we have them.

[Patrick Earl]

The problem is that the NHibernate namespace is commonly used by other
applications, but in this case we're using it for an "internal"
class. It'd be nice to even mark the logger interface as internal,
but we need to make it accessible to other NH-related assemblies. The
work-around is to rename it or put it in it's own namespace. I'm in
favor of it's own namespace myself (given the number of classes that
are there and could potentially be there if further log providers are
integrated into the core). No biggie though, just wanted to get my 2
cents in there. :)

On an unrelated topic, I wanted to say thanks to Fabio and Julian who
have been applying my patches. I feel that my work is valued and that
I'm helping to make a difference in this excellent project. Thanks!

Patrick Earl

[Fabio Maulo]

Don't worry.

We have the adapter for log4net and won't have anything else because the logger is now injectable.

zero config, zero friction, zero breaking-changes, flexible solution, everybody happy.

I'm using NH with Windsor and... zero problem even there... but well... 

http://www.youtube.com/watch?v=ZBvy7mmiD-8&

--
Fabio Maulo

[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.

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

[Fabio Maulo]

2010/9/20 Henry Conceição <henry.c...@gmail.com>

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.

You are talking about "any project/application/framework" you have saw.

I'm talking about "any project/application" I have worked and about "any framework" you have the example of a framework whose only target is the logging abstraction and it does not have neither the ILogger nor ILoggerFactory interfaces.

btw, please, avoid to insist. You have what you asked and the only one reason for this modification is the good relation between NH team and Castle team (even if you have not realized it yet).

--
Fabio Maulo

[Henry Conceição]

Fabio,

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

[Fabio Maulo]

I know we are doing it for the wrong reason.

ILogger is so obvious that CommonLogging does not use it and the only target of CommonLogging is the logging abstraction.

Before your last mail I was 98% sure you have not realized which is the relation between Castle and NHibernate but now I'm 100% sure.

Thanks to give me another well know point in my life.

2010/9/20 Henry Conceição <henry.c...@gmail.com>

--
Fabio Maulo

[Henry Conceição]

So please, explain for me what is the relation between Castle and NHibernate.

Cheers,
Henry Conceição

[Ayende Rahien]

An incestuous one?

2010/9/20 Henry Conceição <henry.c...@gmail.com>

[Fabio Maulo]

On Mon, Sep 20, 2010 at 5:29 PM, Ayende Rahien <aye...@ayende.com> wrote:

An incestuous one?

ROTFL!!! Yes for sure it was incestuous for long time... LOL!!

Now, with the stand-alone Byecode, is more like a partnership.

--
Fabio Maulo

[Jason Dentler]

Oren wins. Thread closed. LOL

[Ken Egozi]

Damn Oren, where did you get that word from? 

--
Ken Egozi.
http://www.kenegozi.com/blog
http://www.delver.com
http://www.musicglue.com
http://www.castleproject.org
http://www.idcc.co.il - הכנס הקהילתי הראשון למפתחי דוטנט - בואו בהמוניכם

[Ayende Rahien]

Google Suggest

[Fabio Maulo]

On Mon, Sep 20, 2010 at 6:29 PM, Ayende Rahien <aye...@ayende.com> wrote:

Google Suggest

WOW!!! googling what ? 

-- 

Fabio Maulo

[Ayende Rahien]

incestus

Which they promptly corrected to the right word

[Tuna Toksoz]

is it like inception? :)

Tuna Toksöz
Eternal sunshine of the open source mind.

http://devlicio.us/blogs/tuna_toksoz
http://tunatoksoz.com
http://twitter.com/tehlike

[Ken Egozi]

that was *my* perception.

[Ken Egozi]

sorry, totally lame, I know.

[Henry Conceição]

Hi Fabio,

Tks a lot for the renaming.

Cheers,
Henry Conceição