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

[James Strachan]

----- Original Message ----- 
From: "Jason Hunter" <  <mailto:jhunter at collab.net> jhunter at collab.net>
> > > 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.
 
Ah got you. I was thinking of Elements that had been added to a Document.
Sorry I understand now. 
 
> > > 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.
 
OK I'm with you now. Cloning is only needed if an element needs to be
"imported" in several places in a document or in several documents.
Otherwise the remove and add mechanism works fine.
 
> > 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.
 
Complexity is undesirable but sometimes we need it ;-)
 
> > 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.
 
Yes this is correct. 
 
This kind of stuff might seem a bit wierd or complex from a general case
'80/20' kind of outlook. 
However the JDK already has this kind of stuff built in for us in Java 2
Collections because some people need to be able to do this kind of thing -
to prevent a large, complex data structure from being mutated by mistake.
The only other solution is to deeply cloning the whole thing, every time
anyone wants it in case they change it. 
 
> > 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.
 
:-)
 
Yes JDOM is not the place to discuss such things, sorry everyone.
 
 
 
<James/>
 

James Strachan
=============
email:  <mailto:james at metastuff.com> james at metastuff.com
web:  <http://www.metastuff.com> http://www.metastuff.com
 


If you are not the addressee of this confidential e-mail and any
attachments, please delete it and inform the sender; unauthorised
redistribution or publication is prohibited. Views expressed are those of
the author and do not necessarily represent those of Citria Limited.