Carsten Ziegeler a écrit :
>
> Sylvain Wallez wrote:
> >
> > Carsten Ziegeler a écrit :
> > >
<snip/>
> >
> > 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.
Damn ! Forgot that one !! Javadoc lists all implementations, but I
mostly look at the code. Maybe this is an example of how rule 2 can also
increase code readability and ease understanding.
Then comes the question : is it good for a low-level component like
AbstractXMLProducer to enforce Poolable ?
> > 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.
> >
>
> +1
>
> > 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
> Recyclable
> and the subclass, too, the subclass will have a super.recycle() in its own
> recycle implementation. Removing the Recyclable interface from the
> superclass
> will then break the subclass unavoidable. (The same applies to Configurable,
> Parameterizable etc., all interfaces having methods.)
Mmmh... most often, you're right. But there are cases where it makes
sense for a method to be totally overriden without calling the
super.method(). In that case rule 2 has some benefits. So let's people
decide on a case-by-case basis.
> 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
> clause
> 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
> > http://marc.theaimsgroup.com/?l=avalon-dev&m=100107230514463&w=2
> >
> > What do you think ?
> >
>
> You mean Poolable and SingleThreaded, I think.
Yes. Sorry for the typo :/
> That thread had the fade a lot of threads have - not only in Avalon,
> but in Cocoon, Xalan, Xerces and I
> 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
> simple
> question "if an action is allowed as a root element in the pipeline".
Yep. And nobody replied to my proposal of just keeping the simple rules
you listed and remove that artificial constraint added by the 64k-limit
patch... I really think this is the way to go, because so much people
have so much different ideas of what rules should/shouldn't be enforced
that I'm afraid nothing clear will come out of this...
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
