[slf4j-dev] NOPLogger methods are final?

[Eric Crahen]

I'm not following at all what you are saying.

My point was, it is very intiutive and straight forward to derive from a
Null Object implementation of a Logger for the purposes of testing. This is
not possible because the NOPLogger included in SLF4J has all methods final.
This means I would have to create my own Null Object implementation that is
not final so I can override methods in a derived class. This requires
writing no less than 49 methods that aren't fun to write.

* The clear draw back to the NOPLogger containing methods is that it can not
be extended. This directly impacts testing with out of the box the standard
SLF4J classes.

* The clear advantage is that with non final methods I do not have to write
a whole new class, or some how modify the SLF4J distribution to get an
extensible NOPLogger. This means that people can very easily write unit
tests to ensure messages are logged properly by an application as the code I
posted previously demonstrates.



On 2/15/07, Boris Unckel <boris.unckel.mlg at gmx.net> wrote:
>
>  Hi,
>
> just the other thread, it is getting late...
>
> Eric Crahen wrote:
>
>
> On 2/15/07, Boris Unckel <boris.unckel.mlg at gmx.net> wrote:
>
>  I think for a common API like SLF4J it is very good to have
> > implementations final:
> >
> > SLF4Js goal is to be used in libraries, other APIs and applications. If
> > there is need to change things,
> > the interfaces have to be stable. The implementations should still have
> > the chance to be changed WITHOUT
> > heavily caring about possible inherited classes.
> >
>
> This is a "no-op" logger. I've carefully considered the fact that the
> inherited implementations of all these components do nothing, and now for
> the purposes of a test case I would like to add some assertions.
>
>  I.e. this is one major problem in the development of log4j - there is so
> > much usage that each very little change
> > has to be proven binary compatible. Thousands of people did not care
> > about using just interfaces and the SPI,
> > they just hacked "quick and dirty" with inheritation of classes which
> > were created with internal use intention.
> >
>
> My code is still written only against interfaces. I'm extending an
> implementation I've chosen to use for a test case.
>
> Yes, it is written against an interface because the NOPLogger is final. If
> it was not final, you would inherit, right?
>
> I think this is a faily useful and straightforward test case that I can
> not write today.
>
>  If someone has need to change something, the license offers full rights
> > to do that. Make a copy and change it.
> > Although there is the decorator pattern....
> >
>
> I can tell you why I don't want to do the decorator pattern.
>
> The Logger and Marker APIs are actually quite lengthy and its more than a
> few lines of code to implement them. To write the test above I had to create
> a NullLogger and implement 49 methods that did nothing; which the NOPLogger
> already does (attached). I don't see any value in keeping the methods of
> NOPLogger final.
>
>  The benefit to make implementation classes of an API final is to have the
> chance to change. As a SLF4J developer you cannot change interfaces, but you
> can change the internal behaviour of any final class as you as developer
> want to without breaking binary compatibility,
> as long as you do not break the contract of the interface. Not breaking
> the contract is much easier to achieve and test as testing binary
> compatibility.
>
> Regards
> Boris
>
>
> _______________________________________________
> dev mailing list
> dev at slf4j.org
> http://www.slf4j.org/mailman/listinfo/dev
>



-- 

- Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/slf4j-dev/attachments/20070215/2d729698/attachment.htm>