[jdom-interest] Parents - why do we need them?

[Amy Lewis]

On Sat, Jun 30, 2001 at 12:21:09PM +0200, Noam Tamim wrote:
>> a fairly unambiguous API for changes.  There are several tactics
>> possible when changing the value of a shared attribute:
>
>This behavior is the one I want:
>
>> 2) if a SharedAttribute value is changed, change its value everywhere.

Yes, but the fact that you want it does not change the fact that other
people may want another style--copy-on-write, enumerated replacements,
and so on.  If there are a *lot* of people who want such a thing
(perhaps they'll speak up?) then it ought to be introduced; if it's not
solving a common problem, then perhaps it should not be--or better,
perhaps, should be introduced in contrib.

>That's the idea: you add the same SharedAttribute object to all of the
>relevant Elements in the tree. In my case, I was building html tables.
>I want every <table> to have the same border attribute, for example,
>border=1. So I have many tables in my document, all of them look like that
>when outputted:
><table border="1" />
>
>When I still have that Document in memory, if I decide that I want the
>border width to be 3. So I just call borderAttr.setValue("3"), and voila:
><table border="3" />

I understand, but may I repeat that this is only one use case of
several possible?  If it's important to you, and you believe it may be
important to others, why not implement it and ask that it be added to
contrib?  If enough other people using the API then say "why is this
over in contrib instead of in main?" it might be moved.

I might suggest that this particular pattern, rather than being called
"SharedAttribute," perhaps could be better referred to as
"RepeatedAttribute," since its major characteristic is that it is
repeated throughout the document, always the same
("RepeatedIdenticalAttribute" might be better, but is too verbose).

>That's the whole idea of "Shared"; my target was definitely not memory
>optimization, but the ability to change the attributes of many elements with
>a single call. Another approach could be to use an Attribute that uses a
>StringBuffer for the value, and exposes it - so I can use the same
>StringBuffer for many Attributes, and change it later.

That might be the most graceful of the possibilities, since it would
provide a fairly trivial way to implement copy-on-write as well, for
those who want that.  Feel like implementing an example?

Amy!
-- 
Amelia A. Lewis          alicorn at mindspring.com          amyzing at talsever.com
Money can't buy happiness, but poverty can't buy *anything*.