[jdom-interest] Announce: JDOMPlus a flexible XML framework for Java

[Jason Hunter]

> > With the interface design (the one that doesn't depend on
> > factories for every object creation) the only advantage 
> > interfaces offer that I can't replicate with base classes is...
> 
> No! You missed the most vital step. Interfaces come with no 
> instance data baggage 

You took the bait!  

> e.g. today right now the sizes of the Element and Attribute are:
> 
> Element has 7 instance variables right now
> Attribute has 3 instance variables right now, maybe 4 soon 
> (parent to handle the sharing / mutation issue).

It's possible to implement Element and Attribute each with just 1
required instance variable.  Basically use association for other data as
needed so memory is allocated to hold an attribute list only if one
exists, for a namespace map only if one exists, and so on.  I too don't
like 7 instance variables, but I expect we can cut it down.  BTW, that
one variable would be reusable in the same model by any sort of
subclass.  So, as I said, that's not a fundamental advantage of
interfaces.

>     List list = new List()
> 
> is much easier than
> 
>     List list = ArrayList();

Following the interface model used by collections, changing from an
ArrayList to LinkedList takes one line of change.  If JDOM followed suit
with the same design, changing from FooElement to BarElement would
require "n" many lines of change.  That's why factories usually come
into play, to get it back to one line of change at the cost of each
later line involving a factory call.

> Interfaces are useful because the implementation is totally open 
> ended rather than having to use the bagagge that you decide upfront.

If reduced instance data is your only argument for an abstract class,
you're discounting the implementation flexibility we have in concrete
classes.

> > The price of that interface
> > architecture is we can no longer declare final methods like
> > equals().
> 
> I don't see that as a big loss.

I suspect that's because you haven't fully understood how JDOM is
designed to work.

> > Also, we'll have this IElement interface that no one uses because
> > they say new Element(),
> 
> Only someone who's doing custom building of an XML tree is affected.
> Readers, parsers, outputters are not affected at all.

If those readers still say "Document d = builder.getDocument()" then the
advantage of the generic interface/abstract class above is nullified,
because they're speaking in terms of concrete classes.

> Incidentally I can not find one line of code in any of the samples 
> in CVS do a "new Element()". 

Only because our samples are minimal.  Look at Elliotte's slides for his
talks and you'll see it used everywhere.

> When I turned Element, Attribute et al all into abstract
> classes, all of the samples compiled and ran correctly without 
> modification.

So you have "Document" as the abstract class.  Thus someone wanting to
construct a new document from scratch would have to say new
FooDocument() and fill it with new FooElement() instances.

>     // I don't want to use a factory here as its complicated
>     // I want an easy life which is a good choice
> 
>     Element element = new DefaultElement( "foo" );
> 
> like they do with collections
> 
>     List list = new ArrayList();
>     List list2 = new LinkedList();

Again, in collections it's a one-line change to switch.  In JDOM it
would be nearly every line changed to switch.  It's a bit apples and
oranges.

> The advantages are a plethora of implementation choices for developers
> without taking a big hit in memory usage. Here's a couple of examples
> 
> * ... (e.g. 1 String for attributes and PCDATA elements

Possible with concrete classes.

> * allow dual tree implementations

This is the most interesting possibility, but not one due to interfaces
or abstract classes but rather just an internal split in the API as was
discussed here.  However, since not many people appeared interested in
having the split and it significantly complicates the API, it's a change
that would be unwise to make at this time.

> * allow nodes and branches to be reused (caching) for use in multiple
> documents by developers who know what they are doing

Possible as a side effect of the above.

> > Now, the other interface model (where factories are used for all
> > object creation) has its own set of problems that people who've 
> > used DOM are familiar with.
> 
> What like?

It's been discussed enough on this list.

> Using a factory is totally optional. There's nothing to stop Brett 
> or anyone else using a 'default standard JDOM' implementation of 
> Element and Attribute throughout his entire code base. e.g.
> 
>     Element element = new DefaultElement( "foo" );

You could say the same for DOM.  But everyone uses the factory.

> You don't have to use a factory when using List and ArrayList and
> LinkedList. Its your choice. I'm advocating a similar stance in JDOM.

I think you're a little fixated on lists.  :-)

> I'm not allowed to implement an Element or Attribute without 
> inheriting all the instance data Brett & you decide should be there.

Well, then you're really going to enjoy my proposal to cut mandatory
instance data down to one reusable variable.

-jh-