Iterator isEqual semantics

[Eric Dean Tribble <tribble>]

let me send this again....
------
To expand upon mr hill's message, I want comparison to be ordered or
unordered based on the COMPILE-time type of the receiver rather than
the run-time type!  I'll propose how to do this (it may be completely
bogus) and then describe a suggestion that MarkM and I worked out that
may supersede this.

Declare isEqual to be a non-virtual in Iterator.  The Iterator
definition would call a virtual function which does unordered compares
(so that a SetIterator could be efficient).  unorderedIsEqual would
have the obvious n^2 definition in Iterator.  Ordered subclasses then
redefine isEqual to do an ordered equality test.  My theory is that
since the memeber function isEqual is defined non-writual, the
compiler will do the lookup at compile-time.

MarkM and I talked about isEqual and what equality means wrt
inheritance hierarchies.  I'll illustrate the general problem with a
specific example:  A is a TextUpdateRecord.  B is a TextDeleteRecord
which is a kind of TextUpdateRecord.  When I say A->isEqual(B), A asks
B about everything defined in TextUpdateRecord and discovers that they
are all identical (the text object that changed, the size of the text,
whatever).  A can't tell that B has more attributed defined than A and
so is in fact not Equal to A.  The test really is a test that B is
upwards compatible from A.  True equality is only the case if
A->upwardsCompatible(B) and B->upwardsCompatible(A).  That means that
either could be substituted for the other.

time to sleep... to be continued...

dean