[jdom-interest] Fast Factory

[Jason Hunter]

>>Perhaps, but for the org.jdom classes I felt pretty comfortable with the 
>>protected methods we expose.  It's the IO packages that have the odd 
>>exposures.
> 
> That's because the only protected methods are setParent/setDocument :) But you
> don't  find "protected ContentList" content and "protected AttributeList" odd?

Certainly.  I figured we'd be privatizing those so I guess they're 
already private in my mind.  :-)

>>>The creation methods can skip verification, but the normal constructors
>>>and set* methods would still call Verifier (guess they could even be made
>>>final).  Sort of a compromise, quick creation for those special cases like
>>>building from SAX, otherwise verify on normal creation or any changes
>>>to a object.
>>>
>>>    Attribute.create(String localName, String value, int type,
>>>                     Namespace namespace)
>>
>>I think this seems like quite a complication if the benefit is only a 
>>bit of performance.
> 
> In what way? It's a protected version of the familiar "newInstance" method
> in other APIs. It has same signature as one of Attribute's constructors and
> a method in JDOMFactory except it can only be used by subclassers.
> 
> My problem with moving JDOMFactory to org.jdom is none of the other classes
> in the package use it. Plus having a public FastFactory in org.jdom works
> good for a little speed up of SAX building but IMHO it's to tempting to misuse.

I guess I'm confused how your proposal solves the problems we'd have 
without your proposal.  Seems like even with a create() method the 
factory will have to be in org.jdom to use it, won't it?  And we'd still 
need two factories, one for normal pluggability and one for SAX built 
use.  (Since you can select a factory in the builder you wouldn't want 
the builders to make direct create() calls.)  Seems like the only 
difference is whether you leave the data fields protected or rely on a 
create() call, and since there's no diff it seems better to leave the 
data fields protected so subclassers can better utilize them.  A static 
create() method does nothing to help subclasses.

-jh-