<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi,<br>
<br>
just the other thread, it is getting late...<br>
<br>
Eric Crahen wrote:
<blockquote
cite="mided0c429e0702151341v3616d88bg27248efaaee47730@mail.gmail.com"
type="cite"><br>
<div><span class="gmail_quote">On 2/15/07, <b
class="gmail_sendername">Boris Unckel</b> <<a
href="mailto:boris.unckel.mlg@gmx.net">boris.unckel.mlg@gmx.net</a>>
wrote:</span>
<div> </div>
<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">I think for a common API like
SLF4J it is very good to have
implementations final:<br>
<br>
SLF4Js goal is to be used in libraries, other APIs and applications. If
there is need to change things,<br>
the interfaces have to be stable. The implementations should still have
the chance to be changed WITHOUT<br>
heavily caring about possible inherited classes.</div>
</blockquote>
<div><br>
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.
<br>
</div>
<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">I.e. this is one major
problem in the development of log4j - there is
so much usage that each very little change<br>
has to be proven binary compatible. Thousands of people did not care
about using just interfaces and the SPI,<br>
they just hacked "quick and dirty" with inheritation of classes which
were created with internal use intention.</div>
</blockquote>
<div><br>
My code is still written only against interfaces. I'm extending an
implementation I've chosen to use for a test case.<br>
</div>
</div>
</blockquote>
Yes, it is written against an interface because the NOPLogger is final.
If it was not final, you would inherit, right?<br>
<blockquote
cite="mided0c429e0702151341v3616d88bg27248efaaee47730@mail.gmail.com"
type="cite">
<div>I think this is a faily useful and straightforward test case
that I can not write today. <br>
<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">If someone has need to change
something, the license offers full rights
to do that. Make a copy and change it.<br>
Although there is the decorator pattern....</div>
</blockquote>
<div><br>
I can tell you why I don't want to do the decorator pattern.<br>
<br>
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.
<br>
</div>
<br>
</div>
</blockquote>
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<br>
can change the internal behaviour of any final class as you as
developer want to without breaking binary compatibility,<br>
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.<br>
<br>
Regards<br>
Boris<br>
<br>
</body>
</html>