[jdom-interest] API Inertia

[Brett McLaughlin]

> Brett McLaughlin wrote:
> >
> > Traversing a tree, which is a 50 line example in DOM (weird
> > structures and all) becomes a tremendous pain in JDOM;
>
> I believe the addition of a real tree traversal API in JDOM would go
> farther to help with this than adding a Node interface containing two
> methods and not changing anything else.  The Java way to walk a tree is
> probably like this:
>
> Iterator itr = doc.getContentIterator();
> while (itr.hasNext()) {
>   Object o = itr.next();
>   // deal with o
> }

What if I want to start iteration at an Element? No commonality? So we've
got to write special-case code for the iterator on Document and Element?

>
> Having a Node interface doesn't really help here because Iterator
> returns Object.  Always will.  You could cast to Node but it'd be

Why? Who says it must? I guess I'm not convinced that assumption is valid.
And if it's simply because of java.util.Iterator, call it TreeWalker or
something and make it return type-safe values. If JDOM is so user-friendly,
so seemingly hell-bent on preventing user error in so many fringe cases, why
wouldn't we return a type-safe value in a very common case?

> useless until you downcast further.  So why not talk about adding the
> above method (which is an idea in the TODO to investigate), rather than
> talk about a Node interface with little value?

Because (1) I think Node has value and (2) the above solution is easier with
a Node interface/base class.

>
> BTW, you could use a visitor pattern for walking too.
>
> > writing the chapters on it. Additionally, with SOAP and things like
that, I
> > really am annoyed in having to get an "Object" back over the wire. I
can't
> > count on it being something that I can feed to, say, XMLOutputter. How
nice
> > would it be to pass a Node, or Item, or whatever, to the print() method
of
> > XMLOutputter? Pretty darn sweet.
>
> There's some value here.  But XMLOutputter would have to do an
> instanceof search to determine what type of object it truly was and then
> use different logic internally depending on the class, because Node
> wouldn't have any helper methods to handle output.  That means you end

So? XMLOutputter internals should not affect the determination of the
usefullness of a method. That is a totally silly argument, IMO ;-) As an API
user, I couldn't care less how hard the API writer has it; I care about what
the API does for me.

> up with a print() method that accepts a general Node interface type but
> in reality it can only *really* print a limited set of implementing
> classes!  That's terrible style, a totally lying interface.

Not true. It would be able to print every implementing class of Node, which
isn't a lie at all. Unless you go to the rather ridiculous, Jonathan Swift
style satire of saying someone defines there own Node implementation that's
nutty and passes it in. Come on; you think people are idiots for not knowing
how to unsubscribe from a mailing list, and expect better, but when writing
code we have to protect them from themselves ;-) Silly..

>
> > Gets rid of all that serialized form crap, for one thing.
>
> It's already gone.  :-)

So how can I print any Node? Well, I have to cast Object to the right thing
and pass it in; that's not as easy as it could be.

>
> >   Things like detach(). This would have never made it into the
> > original API, because we looked at it and said "Oh, here's how
> > you remove content: removeContent()."
>
> I actually discussed the idea before adding detach() months ago looking
> for alternate ideas and *no one* said they didn't like detach().  It
> really sucks to talk about ideas, hear nothing, implement them, and then
> have everyone attack everything.

Fair enough. I completely agree that you threw it out there, and it got
missed. But we're here now ;-)

>
> >   So I simply want to encourage everyone, myself included, to stop
assuming
> > that we are so close that big changes (like namespace handling and
> > entities?!?) are bad.
>
> Umm, I'm confused what point you're making.  We're 110% changing the

Simply that I don't want inertia to be a factor, and I feel that it is, to
some extent. Not to an extreme, but I think there's a "I tried that, and it
didn't work, and there's no way that any light can be shed on it that I
didn't already think of." I'm not sure that's the case. IMO, too many people
are for this idea for it to be a waste of time. It may not be a best
solution, and it's not the only valid solution, but to say it's impossible
to implement is a bit short-sighted, IMO :-)

> Entity model as discussed in the report from the SD West BOF discussion
> and listed in the TODO.  I don't think anyone's against drastic changes
> just because they're drastic, but I am against changes that have serious
> flaws, like Node.  I spent an entire afternoon working on making Node
> work, and I realized every way I tried had dragons.  Now people are

An entire afternoon? <sarcasm>My gosh, you must have exhausted every
possibility. I mean, 4 or 5 hours... that's enough time to write an entire
API</sarcasm>. OK, you had to know that was coming. I think it's possible to
fix this. Very fixable... we're arguing that, and I think it's the truth. As
for if we should do it, there's legitimate disagreement here. But I do think
it's time to acknowledge that it's possible to do this thing, even if not a
30 minute change.

> throwing out many different approaches, and I'm reporting the problems I
> found when I tried the very same thing that afternoon.

I haven't seen implementation problems, for the most part; I've seen
conceptual problems. So we'll keep plugging!

-Brett

>
> -jh-