[jdom-interest] API inconsistency

[Alex Rosen]

I guess this is a slightly different argument than the one we've had several
times, where people think there should be a *single* Node interface for all (or
many) JDOM objects. See the FAQ below for info about that question. (I've sent
this to Jason and Brett for inclusion in the JDOM FAQ.)

You're proposing instead that we have several interfaces, such as Named,
HasParent, HasChildren, etc, right? This is certainly possible, and perhaps
more orderly. But in the real world, is it worthwhile? This would bloat the API
with several extra interfaces, for not a whole lot of extra value. I believe
that in the real world, the number of times that a user will want to operate on
a JDOM object without knowing its type at compile time is pretty rare. (It may
be more common for XML infrastructure code, like an XSLT engine.)

--Alex

Q: Why don't JDOM classes like Element, Attribute, etc. implement a common Node
interface?

A: This issue has been discussed several times on the JDOM mailing list, with
several people on both sides. Jason Hunter summarized the argument against a
common Node interface:

"The problem is that the number of methods which JDOM objects have in
common or could have in common is close to zero.  Therefore to create a
Node we have to either allow methods which don't make sense for all
objects (like getMixedContent() on Attribute) or we have Node as really
just a marker interface.  Myself, I don't want to see non-sensical
methods because that's one of the core problems with DOM.  And I don't
see sufficient value for Node as just a marker interface for reasons
enumerated before.

Some people propose to get more methods into Node by restricting the set
of JDOM objects that would qualify as Nodes.  That tends to come at the
cost of other people's desire for everything in JDOM to be a Node."

Also, this note from Amy Lewis might help:

"...those of us interested in using [a Node interface] can:

1) create a set of custom subclasses that decorate the core classes,
and implement Node;

2) easily keep this set of custom classes synchronized with core;

3) provide a builder that returns these subclasses rather than core;

4) possibly compete with one another in contrib as to what a Node
really looks like, until large numbers of folks go Aha!  That's it!"

For reference, the latest mailing list discussion on this topic started April
29, 2001 with "Ideas for API changes". It continued with "API inertia",
"Philosophical XML", "Design Patterns", and "Common Interfaces".

> -----Original Message-----
> From: jdom-interest-admin at jdom.org
> [mailto:jdom-interest-admin at jdom.org]On Behalf Of Szegedi, Attila
> Sent: Friday, June 22, 2001 9:14 AM
> To: jdom-interest at jdom.org
> Subject: RE: [jdom-interest] API inconsistency
>
>
> Speaking of methods common to multiple classes, I feel
> introducing several
> interfaces would allow for writing cleaner code.
> Right now, if I want to get the name of a JDOM node, I have
> to make a bunch
> of instanceof calls and casts:
>
> String getNodeName(Object node)
> {
>   if(node instanceof Element)
>     return ((Element)node).getName();
>   if(node instanceof Attribute)
>     return ((Attribute)node).getName();
>   if(node instanceof Entity)
>     return ((Entity)node).getName();
>   return null;
> }
>
> If all classes having getName() would implement the
> (not-yet-existing) Named
> interface, I could do it with single instanceof and cast:
>
> String getNodeName(Object node)
> {
>   return node instanceof Named ? ((Named)node).getName() : null;
> }
>
> Of course, Named would include namespace-related name methods as well.
>
> Same consideration holds for getMixedContent(), getParent(), etc.
>
> Attila.