[jdom-interest] (no subject)

[Vadim.Strizhevsky at morganstanley.com]

On Fri, 30 May 2003, Jason Hunter wrote:

> > What really is the point of Parent and Child interfaces and what is a
> > use case of using them?
>
> It makes generic traversal easier.

But it doesn't, that's the whole point. I'm all for interfaces. And I
think the above is a noble and proper goal. Except its not achieved by
these Parent/Child interfaces as they are implemented. The generic
traversal is no easier with them than without them in my view.  Maybe I
just have a twisted view, I don't know.

Brad, said something in his other mail, that is probably right. Its not
really that the interfaces are the problem in so much, (although I still
don't see the value add), it is that the function renaming and Castingthat
they are bringing is a problem for many users. I feel it complicates the
API, but again this is IMO.

> > 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.
>
> This cracks me up.  For two years people have wanted some generalization
> from interfaces, and as soon as they're added some other people want
> them out.

This would be funny if it wasn't so sad. I never sad I want interfaces
out. I'm all for them, I just don't see these as they are implemented as
valuable or achieving anything useful, other than "documentation" as even
Brad says.

> Some things just don't always have a "right" solution and you
> go one way or the other.  Brad's Parent/Child interfaces were the first
> time I saw something I liked more than not having interfaces.
>
> > My understanding was that there was an argument for generic "Node"
> > interface that's mentioned in TODO.
>
> There's been an argument for a generic Node since the beginning.  Of
> course, everyone's idea of what was a Node was different!!  XML is NOT a
> generic tree no matter how nice that would be.  It turns out most Java
> models (JDOM, dom4j, XOM) have decided to use the notion of parent and
> child interfaces although the names aren't always parent/child.
>
> > 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.
>
> They won't be any more type safe!  You could pass "MyBogusThing
> implements Node" and screw up the tree.

Oh please.  Thats a BS argument and you know it. If someone implements an
interface then they oblige to the contract of that interface. I'm not
going to double guess someone who implements this interface. Are you
saying that you're afraid of creating interfaces ouf of fear that
someone may implement it to mascarard someting as X when its not? For
crying out loud.

> We have to check at runtime  what you add regardless.

Actually, if you had nice interfaces for Element, Document, etc.. then
you wouldn't need too, but lets not get into that.

> You don't get any better type safety, and it's
> not like people have real trouble passing in the wrong objects.  There's
> no methods for Node that are common among Parent and Child, so you might
> as well use Object as the generic holder.

But everyone still wants the Node. I wonder why...

>
> > 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?
>
> Except for getParent() there's no place where you have to do a new cast
> that I know of.

Well, that and renaming of all the getChild*. AS I keep saying I'll bet
most JDOM users will shy away from such a huge change...

>
> >>null, so all your doing is trading
> >>
> >>   Child child = element.getChild("foo");
> >>   if (child instanceof Element) {
> >>       Element foo = (Element) child;
> >>       foo.getChild("whatever");
> >>   }
>
> That's not legal code.  You call getChildElement("foo") and it returns
> an Element.

That was btw not my code, but Brad's. And great now I have to rename
getChild which is used EVERYWHRE to getChildElement, without gaining
anything in return.

>
> > I gained absolutely NOTHING in the above example from having a Child
> > interface.
>
> Nope, but you didn't lose anything either.

That's my whole point and you just agreed to it. Nothing was gained
by these changes, but some was lost:

> You just renamed getChild()
> to getChildElement() which is more accurate anyway since getChildren()
> really shouldn't return only elements since elements aren't the only
> "children".

That's a huge loss. Do you realize how much change that is to the users? I
know you think JDOM is beta, and huge changes are ok until JDOM is 1.0 (3
years after the original start). But you know what, at some point its not.
You're just alienating users who really liked JDOM in the beginning,
thought it was a great replacement for DOM, and chose to use it for their
apps. Now you telling them to change in very significant way.

My point in all of this is simple. At the end of day I feel that
introduction of these interfaces and function renames added no value to me
as a JDOM users and only an inevitable pain if I decide to upgrade. Take
that as you will.

-Vadim