Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-Id: <6.0.3.0.0.20041220154754.03c17db8@mail.qos.ch>
Date: Mon, 20 Dec 2004 16:17:03 +0100
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>,
	commons-dev@jakarta.apache.org
From: Ceki =?iso-8859-1?Q?G=FClc=FC?= <ceki@qos.ch>
Subject: Re: [logging] ECL: Log interface vs. abstract class
In-Reply-To: <cq6mvt$bpq$1@sea.gmane.org>
References: <1102738033.4039.24.camel@blackbox>
 <NBBBJGEAGJAKLIDBKJOPMEDLONAB.noel@devtech.com>
 <cq1mot$udg$1@sea.gmane.org>
 <6.0.3.0.0.20041218175610.03a785b0__41157.0719014437$1103391275$gmane$org@mail.qos.ch>
 <41C615EC.5050307@users.sourceforge.net>
 <6.0.3.0.0.20041220144818.03a673e8__28601.7019454905$1103550996$gmane$org@mail.qos.ch>
 <cq6mvt$bpq$1@sea.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable


Aren't you assuming that things can be placed in nice orthogonal and
independent boxes?

Let X and Y be logging APIs that JCL attempts to abstract. Let IX be
an interface unique to API X. Let JCL-IX be JCL's mirror of interface
IX. If the end-user sprinkles her code with JCL-IX calls, there are
two possible branches:

1) API X is available, and there no unintended or unforeseen
interactions between JCL-IX and IX then everything will be fine. If
there are unintended or unforeseen interactions, then this usually
takes a long time to discover, let alone to repair. In the mean time,
your users will be pulling out their hair in frustration.

2) API X is unavailable. In that case, JCL might may attempt to
replace the functionality offered by API X with a NOP implementation or
a simple alternative. However, if API X is considered core
functionality, then the promise of abstraction cannot be not fulfilled
without duplicating the code found in API X.

Writing a good facade is much harder than what people realize. In the
case of competing and divergent APIs, it is an impossible one.

At 03:18 PM 12/20/2004, Matt Sgarlata wrote:
>I disagree; different logging APIs can be supported with the addition of=20
>new interfaces.  Using this strategy, the set of interfaces that a given=20
>Log implementation implements define the set of features which that=20
>logging implementation supports.
>
>Ceki G=FClc=FC 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.
>
>--
>Ceki G=FClc=FC
>
>   The complete log4j manual: http://qos.ch/log4j/


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org