[jdom-interest] API Inertia

[Rosen, Alex]

> Yup. I'm saying that looking back, I can't imagine why I  didn't do this
> thing, because I think it would have made JDOM better. However, a year
> along, it's harder to think about because of the rather massive impact it
> has on so many concepts already in place at JDOM. Make more
> sense? Sorry, I get rambling nights sometimes ;-)

Yup, make a lot more sense now. We agree on this.

However, I'm not arguing against this particular change because it would have a
big impact (I don't think it would, and I wouldn't much care if it did). I just
don't think it would make JDOM better.

> Not if you are trying to do things like serializing. Right
> now, I'm getting an Object, but XMLOutputter needs a specific type for
output.
> I refuse to add output(Object object) to XMLOutputter, but I'd be hapy to see
> output(Node node). Then I could get back JDOM Nodes and
> immediately pass them into the XMLOutputter output() methods. If you are
> arguing for ease of use for the programmer, you certainly have to admit that
this is a lot
> better than having to get the Object (like from a list from
> getMixedContent()), use instanceof to figure out what it is,
> and then pass it back into the right XMLOutputter method.
>
> See, that's my problem: we return generic objects, but then
> require specific ones. It makes life a pain.

I'm still having a hard time coming up with real-world examples where this
would actually be useful. Traversing a JDOM tree and serializing each node
isn't very real-world - you'd end up with a whole bunch of redundant subtrees.
Doesn't sound like something you'd reasonably do.

Calling getMixedContent() and serializing each child is not unreasonable, but I
can't think of any real-world reason why you'd want to do it. You'd still need
to handle Strings specially.

> Not at all... I want a lot more than Elements. I want all the
> content. Yes
> to Entities, Attribute, Elements, ProcessingInstructions...

What about Strings?

> And for this
> case, I am arguing that Node be the case class for all JDOM
> objects. Call it
> something different if you want (JDOMItem, Item, Construct,
> whatever), but
> I'm not getting into all the addContent() arguments, or
> marker interface
> discussions, here. Just wanting some better type safety. We
> know more than
> simply "this is an Object" so we should let the user in on our extra
> knowledge.

The user already knows this. If we provide a tree walker, the user knows we
won't be giving them JButtons. You might think that giving them a compile-time
check for this might help things in some way, but I don't think it will - if
they want to do anything useful with the object, they'll still have to check
its type and cast it. Their code would be identical.

> But I would love a very simple Node (or whatever) interface, with
> perhaps a method
> that provides an Iterator for that Node's
> children/objects/etc. That could really make life easy ;-)

But wouldn't it be wrong? Attributes (etc.) don't have children...

Alex