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

Amy Lewis amyzing at talsever.com
Wed Jun 27 19:01:59 PDT 2001

On Thu, Jun 28, 2001 at 12:14:11AM +0200, Noam Tamim wrote:
>No, I'm not referring to mom and dad. I just wonder - asides from XPath, who
>needs to know about someone's parent?

I can think of a number of possibilities, but they aren't terribly
relevant in the implicit use cases that you propose.

>For example, why can't I use the same Attribute again and again?

Well, is it worthwhile to implement copy-on-write semantics for an
Attribute in order to have fewer instances of otherwise equivalent
attributes?  This is likely to be the case only for certain kinds of
data, and likely to be more useful for attributes that have enumerated
values rather than (for instance) descriptive text or floating point
numbers in a wide range.

One of the issues here is that, supposing you implemented a
SharedAttribute of some sort, then you would have to be able to provide
a fairly unambiguous API for changes.  There are several tactics
possible when changing the value of a shared attribute:

1) if another shared attribute exists with the same name and value as
the new name and value specified, replace the current instance with the
existing instance that has the new value.

2) if a SharedAttribute value is changed, change its value everywhere.

3) if a SharedAttribute value is changed, replace it with a standard

>class SharedAttr extends Attribute {
>    SharedAttr(String name, String value) {
>        super(name,value);
>    }
>    Element getParent() {
>        return null;
>    }

Note that the complexities above should be resolved (in some fashion)
before raising the question whether dropping getParent() is acceptable. 
If a good API cannot be defined that allows the user to make changes
intuitively, choosing (him or herself, not as restricted by a
too-narrow API) which pattern to use, then I would say that the
SharedAttribute should not be modeled.  Perhaps three different (or
more, if I've left out some other way of reacting to a change of value)
types of SharedAttribute should be created.  Perhaps the semantics of
changing a value depend upon the most recent call to a static method on
the class that defines the behavior of setValue for all
SharedAttributes.  Whatever.  But I think it's a problem that ought to
be addressed first; can the result satisfy enough people to be worth
opening the question of making getParent() less useful?

>Using this class everywhere instead Attribute enables me to share the same
>object between several Elements.

Premature optimization is the root of all evil.

It seems to me, given that there wasn't much attention in the original
post paid to the question of what happens when you change a value, that
one of the main purposes of this is to reduce memory footprint.  I
think that, if that's the case, then maybe it should be left as an
implementation detail, or somewhere in contrib, rather than enshrined
in an API that still isn't finalized.

First make it work, then make it right, then make it fast.  And if you
never get it right, don't bother making it fast ... least time between
blue screens is not a badge of honor.

Amelia A. Lewis          alicorn at mindspring.com          amyzing at talsever.com
I stopped by the bar at 3 a.m. to seek solace in a bottle, or possibly a
friend.  I woke up with a headache like my head against a board, twice as
cloudy as I'd been the night before.  I went in seeking clarity.
		-- Indigo Girls

More information about the jdom-interest mailing list