cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: Cleaning up Lifecycle Interfaces
Date Tue, 08 Jan 2002 14:27:11 GMT

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.

> 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) ?

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.

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
http://marc.theaimsgroup.com/?l=avalon-dev&m=100107230514463&w=2

What do you think ?

Sylvain

-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message