[jdom-interest] (no subject)

[Bradley S. Huffman]

Vadim.Strizhevsky at morganstanley.com writes:

> Having separate Parent and Child interfaces seems strange because in most
> cases (Element is the most common case) the same item is both Parent and
> Child. I almost think that you don't want this separation. I.e. have some
> interface "Item", that has both  getParent*() and getChild*() which all
> return Item(s).

But in Element you don't have the separation, it has both the methods of
a Parent and the methods of a Child, like you'd expect :)

> If a particular Item doesn't have a parent, then getParent() should return
> null, same for children. The fact that something has or doesn't have a
> parent seems more naturally determined by whether getParent() returns null
> and not by whether its type is "Child". As even in that case getParent()
> could still return null if its unatached. So you'd have to test both
> whether its "Child" and whether getParent() is null.
> 
> I understand the motivation, that its weird to have Document have
> getParent() function and Attribute have a getChild(), but is it really?

Yes, if they never have a given property why would you want to imply
they could/would by having a method that returns a constant value.
If the docs read "always returns null because this node can never ...",
my first response is "then why is it there in the first place?"

Plus to me it's not very intuitive to define getters (like getChild*()) in
one location ("Item"), and the corresponding setters (if any) in another
location (Element and Document).

> Having two separate Parent/Child interfaces is also very confusing, and I
> don't think really helps to treat the JDOM tree as a "generic" tree, if
> that was one of the goals.

Nope, because it's not a "generic" tree, it's a model of XML which can be
viewed as a tree, but XML has very specific rules about where things can
go.

> Because you have to do the casts below to walk
> the tree. What if you want to walk it down? You'd have to cast the Child
> returned by getChild* to Parent, before you can call getChild again?
> Not very nice either. And if you start puting getParent() into Parent and
> getChild() into Child, than you'll wind up with the same interfaces
> anyway.

But to be robust you going to have to check that getChild didn't return
null, so all your doing is trading

   Child child = element.getChild("foo");
   if (child instanceof Element) {
       Element foo = (Element) child;
       foo.getChild("whatever");
   }

For (which doesn't read as well IMHO :)

   Item item = element.getChild("foo");
   if (item != null) {
       item.getChild("whatever");
   }

What did you save? 1 cast and trade a instanceof for a !=. Jason and I had
a similar discussion because I originally had a "int getType()", and he
argued what's the difference between

    switch(child.getType()) {
    case Child.ELEMENT:
        break;
    case Child.TEXT:
        break;
    case Child.COMMENT:
        break;
    }

And

    if (child instanceof Element) {
    }
    else if (child instanceof Text) {
    }
    else if (child instanceof Comment) {
    }

Is one faster than the other? Is it always? Being someone who prefers not
to try and second guess the compiler, I had to agree he was right and not
argue to keep getType.

Brad