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

[Dave Churchville]

> > It would basically add the following to the Element class:
> > 
> > public void setUserObject( Object o);
> > public Object getUserObject();
> 
> <nit comment="java beans are only good for tool developers">
> What makes this any better, in practice, than
> 
>         public Object user_data;
> </nit>

I think its called encapsulation ;)

> 
> This gets brought up a few times per week. Does no one read the archives
> before posting a RFE?

Yes, but this remains an unresolved issue for me, so I thought I'd try
again.  Subclassing with custom SAXBuilders still isn't that appealing.

> <sarcastic slag="API feature creep">
> For a little more mileage, one could have: 
> 
>         private Map userData = new TreeMap();
> 
>         public void addUserData(String name, Object obj) { ... }
> 
>         public Object getUserData(String name) { ... }
> 
> Then you could add multiple user-data objects - even more flexible. Then every element
> can carry a map around with it. Better yet, why not have a List of unnamed objects and a
> Map of named objects!
> </sarcastic>

<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>