Re: [logging] ECL: Log interface vs. abstract class

[Matt Sgarlata]

I disagree; different logging APIs can be supported with the addition of 
new interfaces.  Using this strategy, the set of interfaces that a given 
Log implementation implements define the set of features which that 
logging implementation supports.

Ceki Gülcü wrote:

Whether you choose Log to be an interface or an abstract class does
not really matter. The point I am trying to convey is that jcl will
not be able to abstract more than one logging API. Although desirable,
abstraction is not technically feasible.
At 12:59 AM 12/20/2004, Matt Sgarlata wrote:
I think this added functionality that is coming in Log4J demonstrates 
another reason to leave Log as an interface rather than converting it 
to an abstract class.  Assuming we make LocalizedLog an interface that 
extends Log, when Log4J introduces support for their new "domain" 
logging (if you will), JCL can just introduce a DomainLog interface 
that extends Log and has nothing to do with LocalizedLog.  A logging 
implementation may or may not support internationalization, and may or 
may not support this new "domain" concept.  In this way, we can have 
Log implementations describe which features they support by 
implementing certain interfaces and not others.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]