[slf4j-dev] NOPLogger methods are final?

[Boris Unckel]

Hello Eric and all,

Eric Crahen wrote:
> Along those same lines a protected default constructor would help too
>
> On 2/12/07, *Eric Crahen* <eric.crahen.lists at gmail.com 
> <mailto:eric.crahen.lists at gmail.com>> wrote:
>
>     Do the NOPLogger methods need to be final? I was hoping to
>     subclass this for use in unit testing. I basically have to write
>     my own NOPLogger in order to be able to override error() and other
>     things at different to assert the correct logging happens. Can
>     these methods be made non-final? People use these through an
>     inteface anyways, is there a benefit I'm missing?
>
>     -- 
>
>     - Eric
>

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

I see this one just the other way round: Make any class final which is 
not part of the public API (Interfaces, abstract classes) and the intended
SPI. Make utitlity classes final. Make all wrappers final.

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

Regards
Boris

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