[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: isEqual: and hash in NSDate
From: |
Adrian Robert |
Subject: |
Re: isEqual: and hash in NSDate |
Date: |
Fri, 22 Jul 2005 13:29:31 -0400 |
On Jul 22, 2005, at 12:44 PM, Richard Frith-Macdonald wrote:
On 2005-07-22 15:57:03 +0100 Adrian Robert <address@hidden>
wrote:
This really seems like a hack (not that it's any worse than the
current state :). Couldn't the implementations of -hash and -isEqual
be aligned without this loss of information? E.g. something like
[warning, sloppy first-attempt code here]:
-isEqual:other
return abs(selfVal - other->selfVal) < epsilon;
-hash
return selfVal / epsilon;
(or maybe (selfVal + epsilon/2.0) / epsilon)
No ... each NSDate has to have its own independent hash ... but
(following the OpenStep spec) dates are equal if they are within a
second of each other.
That means that with dates d1, d2, d3 which have offsets from the
reference date of 0.0, 0.7 and 1.4 seconds,
d1 is eqal to d2 and d2 is equal to d3 but d1 is not equal to d3 ... a
rather counterintuitive behavior!
Right, bad. Thisd could be fixed by changing -isEqual: to simply
return [self hash] == [other hash]
I don't see anything wrong conceptually with stipulating that dates
within some epsilon are isEqual and retrieve the same values as keys in
a hash table, though this might preclude some practical uses. However
OS X compatibility seems the better way to go at this point.
(While we're on this subject, could we change NSEvent timestamps to be
in seconds like OS X (and OpenStep for that matter), instead of
milliseconds?)
Re: isEqual: and hash in NSDate, Jeremy Bettis, 2005/07/22