Re: Equality tests on DOM nodes

Paul Butkiewicz wrote:

> We're getting way into implementation-specific details here, but in the
> first proposed solution:  Suppose we are in an environment that requires us
> to both be able to insert nodes quickly and obtain a node's order quickly
> and we have a large number of nodes.  And we're implementing the first
> solution.  There isn't really a reason that the number has to be an integer,
> is there?  For quick insertion and ordering, we could very well keep two
> integers, numerator and denominator, and if something belongs between 1/1
> and 2/1 we just stick it at 1/2 rather than changing the numbers on the next
> 20000 nodes.  And then, later, when the system is taking a breather, we can
> come back, lock the whole set of siblings, and rearrange the numbers?
>
> Not that anyone actually implements things this way, probably for good
> reason, but if I can't throw out crazy ideas here, where can I?

Yes, or leave huge gaps in your integer values, or use something like a bit
string, where you can keep tacking bits on.  I pursued this type of solutions
for quite a while before I used the BTree solution.  It still gets quite messy
in large situations.  I came up with the BTree solution because it was far less
messy, im my experience, and scaled much better.

It is not clear when you talk about "the first solution" if you mean keeping
consecutive ordering throughout the hierarchy, or only of siblings.  Keeping it
throughout the hierarchy is even less managable.

> P.S.  Ray, you missed my point on the whole Object.equals thing.  My point
> is that if we look to java for guidance (which must make *someone* out there
> cringe :), than the way equals is implemented in String is the exception
> rather than the norm.  I don't think nodes are like strings at all.

I don't think I missed the point.  You didn't say to look to Java for guidance.
You said to look to the default implementation in Java Object, which I argued
does not and can not represent the purpose of equals in Java, which String,
Color, DataFlavor, Dimension, Font, Insets, MenuShortcut, Point, Rectangle, File
... -- any of the 63 classes in jdk1.1.7a that override equals -- do a better
job of representing.

String and these other classes are not the exception.  They are the rule, point,
and whole purpose of having an equals method.  Classes which have not overridden
equals have a less meaningful definition.  I use "equals" on classes which have
overridden it much more often than on those which have not overridden it.  If I
want to know whether two are the same allocation, I will use "==".  If I want to
know if one successfully substitutes for the other without changing meaning, I
use "equals".  There can be ambiguity in judging what should be significant in
the equals call, but it is not unreasonable to expect that the Java DOM binding
might eventually specify some behavior here, which would not be the "=="
comparison.

Ray Whitmer

Received on Monday, 14 December 1998 13:13:19 UTC