[jdom-interest] (no subject)

[Vadim.Strizhevsky at morganstanley.com]

Brad,

Before I answer your points, let me ask this:

What really is the point of Parent and Child interfaces and what is a
use case of using them? How have JDOM API benefited from having them vs
not having them at all like in B9? Can you show examples of use cases
that are now easier to do than before?

As far as I can tell, it only complicated some regular use cases
without simplifying any or providing any more genarility. Jason even
mentioned puting back getParentElement to solve some of these issues.

My understanding was that there was an argument for generic "Node"
interface that's mentioned in TODO. Somehow that morphed into these
Parent/Child interfaces, which IMO don't add any value to API as they
stand right now. Having a single Node interface would for example
allow some apis that work on any JDOM object be more type safe by not
having to pass Object. but with Parent/Child you can't do that.

More below...

On Thu, 29 May 2003, Bradley S. Huffman wrote:

> 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 :)

Right, but not as its returned by any of these functions. So I
wind up using these other methods that return sepcific thigns or
casting. What use are these interfaces if I always cast away?

>
> > 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?"

But not every implementation of this interface would do that. Only
some. I think its perfectly fine to have an interface which in some
implementations has functions that return constant value. That's
just the behavior of that particular implementor and I don't see
anything wrong with that. I don't think its always disqulifies that
function from being in the interface.

>
> 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 iibe 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");
>    }

But what do I need the Child for above? It works just well like this:

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

I gained absolutely NOTHING in the above example from having a Child
interface.

>
> For (which doesn't read as well IMHO :)
>
>    Item item = element.getChild("foo");
>    if (item != null) {
>        item.getChild("whatever");
>    }

But in this case I did gain something from Item interface. One less line,
one less cast. And it does read better to me ;).

>
> What did you save? 1 cast and trade a instanceof for a !=.

Personally I think its better. And both (isntanceof and cast) have non
trivial expense in java as someone else pointed out in another thread.


> 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.

I don't care to argue about instanceof vs getType(), although I
personally hate instanceof. I feel that if you have to resort to use
instanceof to often tha your API/Interfaces are not done well.

But anyway, I still fail to see what Child interface as it is right now
really adds to JDOM, other than muddy the waters.

-Vadim