[jdom-interest] Element Reference from Attribute

[Rosen, Alex]

<< The effect on the API is suprisingly minimal. The following standard JDOM
objects are now immutable, so can be shared across any Element and Document
instances..
    Attribute
    Entity
    Comment
    CDATA

There are new doubly linked, mutable versions of these...
    AttributeNode
    EntityNode
    CommentNode
    CDATANode >>

I like this general idea. I'd like to propose a slightly different
technique, which lets us have only one API, rather than two very similar but
not identical APIs. Just put all methods (getParent(), setValue(), etc) on
both sets of classes, but have them throw exceptions on the base class. This
is not unprecedented; the Collections API (which we seem to be so fond of)
does this with all of its mutation operations (see the add(), remove(), etc.
methods on java.util.Collection). It throws an UnsupportedOperationException
when the particular collection implementation doesn't support a particular
method. JDOM could do the same.

With this change, there's no need to overload the API with multiple
type-safe methods like getAttribute() and getAttributeNode(). And, you only
have to learn one set of interfaces, since the methods on Attribute and
AttributeNode are identical. By default, the builders would generate the
fully-functional subclasses, but could be set to create the memory-saving
base classes by people who knew what they were doing.

Another benefit is that XPath and the like can refer to only one set of
classes, without having to cast back and forth, and still be maximally
flexible in which set of classes it takes. You'd like for XPath to work with
the memory-saving classes as much as possible, and to only require the use
of the fully-functional classes when evaluating a compilcated XPath that
needed the extra functionality, like getParent(). So the XPath API would
have to take Attribute objects in its method signatures, but cast to
AttributeNode whenever it wanted to call getParent(). With this new
technique, no casting would be necessary.

Since both sets of classes would implement Node, I'd propose that the
classes be named MinimalAttribute and Attribute, or something like that,
instead of Attribute and AttributeNode.

--Alex