cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: [C3] Refactoring the SAX module
Date Tue, 17 Feb 2009 21:06:45 GMT
Steven Dolg wrote:
> Just random thoughts (and I must admit I haven't thought about the
> changes in detail):
> * Extending some abstract classes is all that was necessary all the
> time. 

> Getting rid of some of the interfaces implemented by those
> abstract classes actually changes nothing for a developer but makes
> things like AOP (at least sometimes) a lot harder.
Maybe, but I don't think in this case.

> * Forcing a developer to add his classes to our class hierarchy
> eliminates any possibility of building his own class hierarchy and
> implementing the interfaces directly (this might not be necessary in the
> most cases, but I see no reason to eliminate this option completely)
Oh, that's still possible of course.

> * Duplicating code to make the class hierarchy "even simpler" (whatever
> that means) seems like a pretty bad idea IMO. Code duplication has
> almost never done anything good for me (besides being quick & dirty -
> which is usually just dirty and not quick at all if you intend to work
> with the code for quite some time).
LOL - sorry, couldn't resist - now, I totally agree with you in general,
but in this case it's duplication of never changing code - it might be a
bad idea, but on the other hand, as I repeatedly said: there are imho
already a lot of interfaces and abstract classes involved. And this is
confusing to new people.

> * Replacing the SAXConsumerAdapter with the SAXPipe means it cannot be
> used as a surrogate destination for a SAXTransformer or adapter for a
> ContentHandler (which was the intention behind this class) - so how can
> it actually replace it (or has the contract between SAXProducer and
> SAXConsumer changed)?
Yes, it changed - there is no consumer and producer anymore. The SAXPipe
implements ContentHandler and that's all what is required.

> * Without any more detail it's impossible to fathom the
> meaning/implications of those changes.
Ok, I've attached the patch to

> So is this about having a developer still extending
> AbstractSAXGenerator, AbstractSAXSerializer, AbstractSAXTransformer
> (which all exist now) but making the class hierarchy above (as in
> towards java.lang.Object) less deep/wide by removing interfaces/abstract
> classes implemented/extended by those classes?
Yes, it's about removing ballast - now, as you said, for the average
developer there are no real changes as there are still the abstract
classes of course.

> And sorry for asking again, but what's the rationale behind "reduce the
> number of interfaces and abstract classes as much as possible"?
No problem, the rational is to make this "beast" easier to understand.
Look at the current sax module and browse the hierarchy of interfaces
and abstract classes. I know Cocoon and most of this stuff for years,
but it took me some time to find out what is there and why and how
things work. Maybe it's me getting old, but I hope not :)
So why not simply having just the stuff there which is really needed?
Try to explain the difference between the existing abstract
classes/interfaces :)

Carsten Ziegeler

View raw message