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

[Patrick Dowler]

On Wed, 29 Nov 2000, Brett McLaughlin wrote:
> I have to, at this point, step in and say that I'm firmly (now) against 
> this. While I've been monitoring the discussions for several days, and 
> appreciate all of James' hard work, the complexity is spiralling. I'm 
> also now beginning to see statements like "to support this [new] idea, 
> we must change and throw out old ideas" For example, to support this, 
> pulling Element into an interface and abstract class seems neccessary. 
> Of course, I'm strongly against this for all the reasons that I was 
> against it over the last year (see the mail archives and anywhere the 
> word DOM occurs ;-) ).

As the other proponent of splitting Element into a base class and derived
class, more or less along the lines of singly-doubly-linkedness, I am 
very disappointed with how this has gone. The basic idea is extremely
sound and simple. I guess I don't have the enthusiasm that James has so
he has run off and implemented it and gotten all excited about what could be
done. That's fine, but shouldn't be used to discredit the whole idea. 

As for me, my position is that this is a simple split of basic XML stuff
(elements with children and attributes, namespaces, documents and
doctypes, and IO) - the things that let someone read and write XML - 
from a much more powerful data structure that mets things like XPath,
XInclude, etc work well. I agree 100% that we need all these features.
I also feel 100% sure that separating these into two classes makes a lot of
sense from a flexibility/use point of view. Putting all the functionaility into a single
class (or set of classes when you consider 2-tier Attribute, for example) is
clearly substandard because you are arbitrarily tying together things that are
not necessarily related.

All this stuff about interfaces and proxies is way to complicated for little gain.
Scrap it. Fine.

My original basic idea is to have an base class with basic XML
and a subclass with power features, except that the base class is not abstract
so it can be used directly. What I'm doing is turning back the clock about 6-8
weeks to the point where basic XML could be read/written/created and
then adding new features to a subclass instead. 

It isn't too late for this and it has almost no impact on any existing code.
The advantages are very large for someone who needs to handle huge
but simple XML data files (my main use), amoung other things.

The downside is not slight, however, and I haven't yet come to a satisfactory
conclusion. It is simply this. Say I have:

class Element
{
   public Element getChild(String s) { ... }
}

class DerivedElement extends Element { ... } // needs better name, clearly!!

If I build a tree out of DerivedElements, the getChild method returns an
Element and I have to cast to call the special methods. The instanceof 
checking isn't so bad, since all the elements of a tree have the same type 
as the root element, but still I'd have to cast alot if I wanted to use the special 
features of DerivedElement. This would not be nice for XPath-using code, for 
example. 

One suggestion was to put all the method signatures into the base class. For
an abstract class this is OK, but since we want to be able to use the lean
base class, the methods that don't make sense would have to throw
an UnsupportedOperationException. This is somewhat unpleasant, but it 
would be something that would only catch people who were messing around 
without reading the docs, because:

*** DerivedElement would always be created by default unless the user takes
      some measure to use Element ***

Thus, these exceptions would never be thrown at an unsuspecting user of
JDOM. Basically, we have an abstract base class that isn't technically declared 
abstract so people can make use of what it does implement IF that is enough 
for them. 

Consider the base Element for "expert use only".  In effect, people 
would write code that used Element as the type everywhere except that 
they'd have to call "new DerivedElement" instead. (The alternative of 
BaseElement and Element means that method signatures refer have 
BaseElement, which is worse.)

BTW, if we want any kind of subclassing support at all, the Builders have to
support factories, so that is unavoidable. The DefaultFactory would create
DerivedElements.

> I think this is clearly outside of the 80/20 rule, maybe even the 95/5 
> rule. Nobody is seeming to speak up for it, either, which makes me think 
> that it is not serving a common cause. Again, I hate to sort of nix such 
> a large amount of work by James, but people just don't get this, and 
> don't really want to pay the heavy prices associated with it.

The original idea has little impact on complexity. It's always easy to get carried 
away :-)
 
> Right now, elements are elements, not immutable, or mutable, we don't 
> have nodes that can't be modified, we don't have DOM-isms, which are all 
> the things being introduced by this approach. Sorry... I just can't see 
> this being a good thing for JDOM.

I don't think anything should be immutable beyond the current things (Element
names, for example). People who don't do anything will be using the safely
mutable DerivedElement; those that bypass this and use Element should know
what they are doing. 

Well, maybe we should all know what we are doing :-)

-- 

Patrick Dowler
Canadian Astronomy Data Centre


PS - A secondary benefit of splitting this is that the base Element class has the
non-contentious stuff, while DerivedElement could be re-implemented in a
variety of ways to experiment with alternate implementations of support features.
If we have a single Element class, then you can either (1) redo everything or (2)
subclass it and carry around all the baggage you are trying to improve upon.
This makes it tough for people to write alternative implementations of the 
extended functionality, IMO.