[jdom-interest] Re: carrying user data around with Element

[David Churchville]

> > <flame-retardent>
> > For all of the many possible uses of user data, its a pretty good "bang
> > for the buck" feature creep.  It doesn't even require testing, exactly.
> > Why is something to flame about?  My question was as to whether there
> > are substantive objections to adding this?
> > </flame-retardent>
>
> It is quick and easy, to be sure. It is also not type safe, so you have to
> "know" what is there and cast, or use a bunch of instanceof and cast...
>
> I understand that the thinking so far is that a subclass with user data
> (which isn't really in any danger of breaking when the base class changes,
> BTW) is the better route because you get type-safety for your app and
> you can do the software engineering thing and ensure some sort of
> state-invariant. A generic user object doesn't let you have either, so
> anything beyond a trivial project wouldn't likey use it anwyay.

I think that while this is theoretically true, its likely that for 80% of
the cases where you want to carry around extra data, its sort of acceptable
to have a "user object" that is carefully controlled by the app.  Obviosuly
if the app sets *different types* of user objects on a set of elements, this
does lead to the things you describe, but a *single type* of app-defined
user object that can be carefully engineered (like the kind I would write
:-^  ).  This is just design with composition instead of inheritance.   I
would argue that this type of composition is necessary anyway, since not all
app objects would be able to subclass Element (instead of implementing an
Element interface), due to the single inheritance limit.

Anyway, the point of JDOM is ease of use and convenience, so it would be
nice if it were convenient and easy to carry around extra data.  Subclassing
+ writing a special SAXBuilder, DOMBuilder, etc. is not convenient or easy.
Earlier I asked about a "standard" SAXBuilder, etc. that would allow
user-supplied Element implementations, but this was deemed to not be a
desired JDOM direction.  User objects are my last hope at something
straightforward!

--Dave