[jdom-interest] Code submision: JDOM2 the dual tree implementation...

[Jason Hunter]

> > > Validator interface or abstract base class which is a property
> > > of Document (for use in doubly linked trees)
> >
> > If validation is a property of Document, then elements are tied to
> > document (bad)
> 
> They already are. Doubly linked Element has getDocument() and
> getParent() methods so an Element is currently tied to its parent 
> elements and the document.

No, elements are not necessarily part of a document.  They can exist
separately.  

Element e = new Element("foo");

What I'm saying is that an element on construction like this doesn't
have a Document it can refer to for behavior toggles.

> > or elements have to be imported to a document (bad)
> 
> They already do don't they? Right now you have to deep clone to get an
> Element from one document to another.

No, of course not.  Take an element, remove it from its original place,
then add it to its new place.  Voila.  No import required.

> > or
> > element have to be background-checked when added to a document (bad for
> > efficiency, plus impossible with a singly linked tree).
> 
> Agreed. Let's quitely ignore incremental validation for now shall we? ;-)

Definitely.

> you could use singly
> linked immutable leaves with mutable doubly linked Element you wish.

Yes, but it's no longer a singly-linked tree, so the metaphor for
interacting with "nodes" will vary depending on if they're elements or
other kinds of nodes.  That's undesirable.

> So we could have an ImmutableElement implementation which proxies the

An immutable element adds a great deal of complexity.  You'd have to
always create a mutable element first before making it immutable
otherwise it could have no children.  And then you'd have this weird
side effect as you added immutables to mutable trees, and if you wanted
an immutable added to an immutable, well, you can't.  Cuz it's
immutable.

> I'm now starting to think that, although it adds some complexity, 
> an Element interface (or abstract base class with no instance data)
> might be a good idea. Then we could implement a proxy Element...

You'll find great resistance to going with interfaces.  Someday I'll
write a formal FAQ answer to "Why don't you use interfaces?".  The
answer will be quite long.

-jh-