cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: Cleaning up Lifecycle Interfaces
Date Tue, 08 Jan 2002 14:47:52 GMT
Sylvain Wallez wrote:
> Carsten Ziegeler a écrit :
> >
> > Hi,
> >
> > I just reviewed a little bit of the serializers code, and saw this:
> > AbstractSerializer implements: Recyclable
> > AbstractTextSerializer inherits from AbstractSerializer and implements
> > Poolable
> > TextSerializer|XMLSerializer... inherit from AbstractTextSerializer  and
> > implement Poolable
> >
> > This seems to me that there are too many implements in this inheritance
> > chain.
> You can remove Recyclable from AbstractSerializer... but it will still
> be Recyclable because it extends AbstractXMLProducer (through
> AbstractXMLPipe) which itself implements Recyclable !
> The main reason for AbstractXMLPipe to be Recyclable is to break the
> link with its XMLConsumer and thus allow it to be GC'ed.

Yupp! Another one in the chain. I just forget it to mention.

> > Before I start doing something, is is OK to remove the two
> > implements Poolable statements (from AbstractTextSerializer and
> > TextSerializer|XMLSerializer
> > etc)?
> Why don't you want them to be poolable ? Since they rely on Trax
> transformers for serialization, it is IMO good for performance to have
> them poolable. Or do you want to remove implements for interfaces
> already implemented by super-classes (i.e. only on TextSerializer &
> XMLSerializer) ?

It seems that I didn't make me clear: Recyclable inherits from Poolable,
so if a superclass is already Recyclable, it is superfluous to implement
this interface (or Poolable) in one of it's subclasses.

> Now this comes to the coding rules we could adopt regarding interfaces
> (be them lifecycle interfaces or not). I see to possible rules :
> 1 - a class shouldn't explicitly implement an interface which is already
> implemented by any of its superclasses.


> 2 - a class should explicitly implement every interface whose methods it
> redefines, even if already implemented by one of its superclasses. It
> should also implement marker interfaces which it relies on (e.g.
> SingleThreaded for statefull classes).
> IMO, rule 2 leads to more robust code, since it prevents
> lifecycle/lifestyle of a class to be broken if an update to one of its
> superclasses removes the implementation of an interface.

No, unfortunately this is not true! If a superclass used to implement
and the subclass, too, the subclass will have a super.recycle() in its own
recycle implementation. Removing the Recyclable interface from the
will then break the subclass unavoidable. (The same applies to Configurable,
Parameterizable etc., all interfaces having methods.)
So I think, that the lifecycle behaviour of an implementation can only be
changed if there is no subclass. And this leads me to your rule 1: as the
superclass lifecycle can never change, I can (and must) rely on this and
therefore do not need to explicitly state this interface in the implements
of a subclass.

> This also reminds me of a discussion you started some time ago on
> avalon-dev to have Poolable extend ThreadSafe. I tried to second you,
> but this proposal didn't got acceptance at that time... See
> What do you think ?

You mean Poolable and SingleThreaded, I think. That thread had the fade
a lot of threads have - not only in Avalon, but in Cocoon, Xalan, Xerces and
guess in many other projects as well. Someone has an idea/suggestion and
this starts a mind-blowing thread where a lot of developers throw their
ideas in and suddenly all loose interest and nothing really happens.
I can't count the votes and suggestions I started in the last 6 weeks here
in the Cocoon list without a result. Just see what has happened to the
question "if an action is allowed as a root element in the pipeline".


To unsubscribe, e-mail:
For additional commands, email:

View raw message