[jdom-interest] Simpliyfing Filters

Alex Rosen arosen at silverstream.com
Fri May 3 09:03:47 PDT 2002


Jools liked canAdd() and canRemove() because they might help in creating a
read-only tree. I didn't think they were necessary for that, and that there
were enough open questions about how a read-only tree would work that this
case wasn't worth considering. The only other reason for canRemove() was to
not allow you to remove the root element from a document, to force you to
use setRootElement() instead. But nowadays I think it's OK to have a
rootless document temporarily, right?

> Currently the filter code restricts (in the List interface) adding only
nodes
> that match canAdd() in our filter, but do we really care? As long as the
node
> is legal content for a given situation, isn't that good enough (same logic
as
> ERH post on setChildren)?

In other words you should be allowed to add a Comment to a getChildren()
list, but you still shouldn't be able to add a JLabel, right? I don't really
have an opinion on this, as long as the checking for legal types (e.g. no
JLabels) still happens somewhere.

> Removing canAdd() and canRemove() would not have any effect on
performance.
> A live filtered List has rotten performance anyway since there is no way
to
> determine size() or the index of a node without scanning the list each
> time (hence the suggestion to List.listIterator).

IIRC the tests I did showed that the live lists were surprisingly
inconsequential in their performance impact once created. I think the extra
object creation hurts us though.

Alex




More information about the jdom-interest mailing list