you [...] aren't allowed to mutate objects that are in collections
Where is that documented? I've been doing this without consideration
and nothing's blown up yet.
How is a method to know if an object it's been passed is in a
collection? Equally how are you to know if a method is going to
This is the gist of it, I think. NSArray and NSDictionary should be
safe to store mutable objects, since they use an index or a key for
storage position, and not the object (the value) itself.
So (as I understand it): You *are* allowed to mutate objects in
collections, but only if the
IIRC, isEqual: compares memory addresses, whereas isEqualTo: compares
hashes of the objects being compared. I also believe that isEqual: is
the preferred method.
Cheers,
Dave
On Sep 18, 2008, at 3:57 PM, Rick Mann wrote:
I see that NSObject (and its protocol) define -isEqual: and -
On Sep 18, 2008, at 2:59 PM, Dave DeLong wrote:
IIRC, isEqual: compares memory addresses, whereas isEqualTo:
compares hashes of the objects being compared. I also believe that
isEqual: is the preferred method.
isEqual: does not compare addresses. That's what == is for. Two
distinct
On Sep 18, 2008, at 5:15 PM, Charles Srstka wrote:
On Sep 18, 2008, at 4:59 PM, Dave DeLong wrote:
IIRC, isEqual: compares memory addresses, whereas isEqualTo:
compares hashes of the objects being compared. I also believe that
isEqual: is the preferred method.
The documentation says
On Sep 18, 2008, at 15:15:11, Charles Srstka wrote:
According to the documentation, isEqualToString: is faster when you
know both objects are strings. I'm not sure what isEqualTo: is for,
though.
Thanks to all for the answers.
I thought isEqualTo was a method on NSObject, but I realize
On Sep 18, 2008, at 6:23 PM, Rick Mann wrote:
I thought isEqualTo was a method on NSObject, but I realize now it's
part of the NSComparisonMethods Protocol.
The whole thing strikes me as a bit messy.
Also note which header that category lives in - NSScriptWhoseTests.h.
That provides
if two objects compare equal, then they must have the same hash
[...] [you] have to implement a corresponding -hash that maintains
this invariant rule.
Is there an example somewhere of what one should do to implement -hash
to reflect -isEqual:, I haven't done so in one of my classes and it
On Thu, Sep 18, 2008 at 4:19 PM, Keith Duncan [EMAIL PROTECTED] wrote:
if two objects compare equal, then they must have the same hash [...]
[you] have to implement a corresponding -hash that maintains this invariant
rule.
Is there an example somewhere of what one should do to implement -hash
On Sep 18, 2008, at 7:32 PM, Shawn Erickson wrote:
On Thu, Sep 18, 2008 at 4:19 PM, Keith Duncan [EMAIL PROTECTED]
wrote:
if two objects compare equal, then they must have the same hash
[...]
[you] have to implement a corresponding -hash that maintains this
invariant
rule.
Is there an
On Sep 18, 2008, at 4:39 PM, Jim Correia wrote:
On Sep 18, 2008, at 7:32 PM, Shawn Erickson wrote:
On Thu, Sep 18, 2008 at 4:19 PM, Keith Duncan [EMAIL PROTECTED]
wrote:
if two objects compare equal, then they must have the same hash
[...]
[you] have to implement a corresponding -hash
On Sep 18, 2008, at 5:33 PM, Ken Thomases wrote:
Another counterexample is an object which doesn't provide value
semantics. That is, its -isEqual: only tests identify (pointer
comparison) and whose hash is purely based on the object pointer.
..or say a person object which is considered
On Sep 18, 2008, at 8:36 PM, Shawn Erickson wrote:
On Sep 18, 2008, at 4:39 PM, Jim Correia wrote:
Additional care must be taken if you are implementing a mutable
object and intend to store it in a collection: the object's -hash
cannot change while it is in the collection (so effectively,
On Sep 18, 2008, at 8:54 PM, Jim Correia wrote:
Since mutable framework provided objects can (and do) change hash
values as they are mutated, I agree with your tenuous classification
of the situation. In the general case, storing mutable objects in
hash-table like collections outside of a
14 matches
Mail list logo
