[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Iterator isEqual semantics
- To: <us>, <tribble>
- Subject: Iterator isEqual semantics
- From: Eric Dean Tribble <tribble>
- Date: Wed, 6 Sep 89 14:17:55 PDT
- In-reply-to: <eric@son-of-blob'smessageofMon>,10 PDT <8909050354.AA01615@xxxxxxxxxxxxxxxxxxxxxxx>
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...