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. > +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.) 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. 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". Regards, Carsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
