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: neutral (hermes.apache.org: local policy)
Subject: Re: [digester] initial code for Digester2.0
From: Simon Kitching <skitching@apache.org>
Reply-To: skitching@apache.org
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
In-Reply-To: <20050202140444.53695.qmail@web52306.mail.yahoo.com>
References: <20050202140444.53695.qmail@web52306.mail.yahoo.com>
Content-Type: text/plain
Date: Thu, 03 Feb 2005 11:50:30 +1300
Message-Id: <1107384630.4217.42.camel@blackbox>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Wed, 2005-02-02 at 06:04 -0800, Reid Pinchback wrote:
> --- Oliver Zeigermann <oliver.zeigermann@gmail.com> wrote:
> > On Wed, 02 Feb 2005 18:28:04 +1300, Simon Kitching <skitching@apache.org> wrote:
> > > My major concern is that if we are going to warn people not to implement the Action interface,
> > > then what really is the point of providing it in the first place? As I said above, I just
> > cannot
> > > think of any situation where a class would want to be an Action *and* extend some other class.
> >
> > I am +1 for using an interface and the default (why abstract?)
> > implementation like with Swing or SAX.
> 
> I don't get why we would ever warn people not to implement the interface

We (digester developers) want the ability to add methods to Action in
minor releases. But adding methods to an interface breaks all classes
that directly implement that interface.

So people should not extend an Action interface because their classes
could be broken by a minor-version update of Digester, eg 2.0 -> 2.1.

They wouldn't be forbidden from implementing Action, just warned about
the consequences.

By encouraging users to extend AbstractAction instead of implementing
Action, we have the chance to provide default implementations for new
functionality, and thereby give ourselves the chance to improve digester
in minor releases without breaking user code.

> Here is a concrete example of why you could want to implement the interface
> and extend another class, I've actually had situations with the existing
> Digester where I'd wished I could do that.  The one that I can recall now
> was an instrumentation issue.  Doing debugging and performance tuning of
> a suite of rules can be tedious because, currently, the only options are
> either to watch a spew of logging messages or single-step your way through
> all the callbacks in a debugger (PAIN).  If the major coupling points
> in the Digester had been abstracted by interfaces, it would have been
> easier to insert instrumentation proxies or EasyMock'd test implementations 
> of classes at key points.

I don't know much about EasyMock, and have only rarely used
java.lang.reflect.Proxy.

But if having an Interface rather than an abstract class makes it easier
to use these, then that's a very good point in favour of Colin Sharples'
recommendation to create Action (interface) + AbstractAction (class).
Normal code extends AbstractAction, but instrumentation code can proxy
the interface if it really needs to.

And as these uses of the interface are "transient", we don't have to
worry about "breaking" code when the interface is modified, right?


Does this satisfy your concerns?


Regards,

Simon


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