On Aug 20, 2009, at 9:09 PM, Jeff Laing wrote:
If you need to know whether or not another object has put your object
into an NSDictionary, you're probably doing something wrong. Do you
have a specific concern about Core Data using your objects ?
No, I guess the point I was trying to make
On Aug 20, 2009, at 22:19, Adam R. Maxwell wrote:
On Aug 20, 2009, at 9:44 PM, Quincey Morris wrote:
The keys in a dictionary (or other keyed collection, like a map
table) need to be immutable objects, but that's unrelated to the
hash. Mutability in the keys would be bad, hash or no hash.
On Aug 20, 2009, at 23:24, Adam R. Maxwell wrote:
It was not my intent to beat up on you, so I apologize if I came
across that way!
Nah, I was just kidding -- and trying to distract your attention away
from the fact that I didn't have a better answer.
On 21 Aug 2009, at 03:45, Jeff Laing wrote:
The -hash method is important for objects that are used as keys in
associative collections.
[snip]
So, in practice, it's perfectly safe in 99.9% of cases to base your
hash off your object's properties. In the specific case when you're
mutating
On 21 Aug 2009, at 04:51, Seth Willits wrote:
On Aug 20, 2009, at 2:31 PM, Alastair Houghton wrote:
The -hash method is important for objects that are used as keys in
associative collections.
The documentation, nor did many others' comments on this topic, make
it clear that the
On 21 Aug 2009, at 05:44, Quincey Morris wrote:
On Aug 20, 2009, at 20:51, Seth Willits wrote:
The documentation, nor did many others' comments on this topic,
make it clear that the mutability is only a problem for the *keys*.
Others and the docs talk about (paraphrasing) putting an object
On 21 Aug 2009, at 06:48, Quincey Morris wrote:
On Aug 20, 2009, at 22:05, Jeff Laing wrote:
If a mutable object is added to a collection that uses hash values
to determine the object’s position in the collection, the value
returned by the hash method of the object must not change while
Le 21 août 2009 à 10:55, Alastair Houghton a écrit :
On 21 Aug 2009, at 05:44, Quincey Morris wrote:
On Aug 20, 2009, at 20:51, Seth Willits wrote:
The documentation, nor did many others' comments on this topic,
make it clear that the mutability is only a problem for the
*keys*. Others
No, not true.
Key values cannot be mutated while used in a collection, period.
Correct.
Excuse my intrusion in this discussion, but I don't really
understand why 'isEqual:' and 'compare:' results must not change
when an object is used as key.
My though was that as long as the hash
On 21 Aug 2009, at 10:07, Jean-Daniel Dupas wrote:
Excuse my intrusion in this discussion, but I don't really
understand why 'isEqual:' and 'compare:' results must not change
when an object is used as key.
My though was that as long as the hash remain the same, it should
not be an issue. I
On 21 Aug 2009, at 10:31, Alastair Houghton wrote:
On 21 Aug 2009, at 10:07, Jean-Daniel Dupas wrote:
Excuse my intrusion in this discussion, but I don't really
understand why 'isEqual:' and 'compare:' results must not change
when an object is used as key.
My though was that as long as
On 21 Aug 2009, at 10:52, Richard Frith-Macdonald wrote:
On 21 Aug 2009, at 10:31, Alastair Houghton wrote:
In the current implementation, I think you're probably right that -
isEqual: and -compare: could change their results as long as -hash
stayed the same.
I very much doubt that.
AFAIK, NSDictionary specifies that it COPIES keys, and RETAINS
objects. Thus even if you were to use an NSMutableString as a key, you
could not mutate the key in the NSDictionary. So the only way you are
likely to get into trouble with keys is if you do troublesome things
like use oddball
On Fri, 2009/08/21, Quincey Morris quinceymor...@earthlink.net wrote:
From: Quincey Morris quinceymor...@earthlink.net
Subject: Re: When do I need to override hash?
To: cocoa-dev cocoa-dev@lists.apple.com
Date: Friday, 2009 August 21, 00:48
On 2009 Aug 20, at 22:05, Jeff Laing wrote
From the docs:
If a mutable object is added to a collection that uses hash values
to determine the object’s position in the collection, the value
returned by thehash method of the object must not change while the
object is in the collection. Therefore, either the hash method must
not
On Aug 20, 2009, at 12:00 PM, Seth Willits wrote:
Returning 0 is certainly simpler :p
It is, but you can generally do better than just returning 0, usually
by just extracting some bits from 'self', ala
-(NSUInteger)hash
{
uintptr_t hash = (uintptr_t)self;
return (hash
On Thu, Aug 20, 2009 at 12:33 PM, David Duncandavid.dun...@apple.com wrote:
On Aug 20, 2009, at 12:00 PM, Seth Willits wrote:
Returning 0 is certainly simpler :p
It is, but you can generally do better than just returning 0, usually by
just extracting some bits from 'self', ala
Why do you say that? I haven't noticed any documented requirement that
ties the implementation details of -hash and -isEqual together.
- Bryan
Sent from my iPhone
On Aug 20, 2009, at 4:27 PM, Clark Cox clarkc...@gmail.com wrote:
On Thu, Aug 20, 2009 at 12:33 PM, David
-isEqual: is how Cocoa collections define equality. Saying that two
objects are equal means, by definition, that -[obj1 isEqual: obj2]
returns true.
On Thu, Aug 20, 2009 at 1:30 PM, Bryan Henrybryanhe...@mac.com wrote:
Why do you say that? I haven't noticed any documented requirement that ties
From
http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Protocols/NSObject_Protocol/Reference/NSObject.html#//apple_ref/occ/intfm/NSObject/hash
If two objects are equal (as determined by the isEqual: method), they
must have the same hash value. This last point is particularly
On Thu, Aug 20, 2009 at 1:33 PM, Clark Coxclarkc...@gmail.com wrote:
-isEqual: is how Cocoa collections define equality. Saying that two
objects are equal means, by definition, that -[obj1 isEqual: obj2]
returns true.
This has nothing to do with -hash.
P: Two objects are equal.
Q: They have
Yes, but the problem with a hash based on the pointer is that it
limits your isEqual implemenation from being based on anything more
than the pointer, or you violate the If objects are equal, they must
have the same hash rule.
(Earlier email was a brain fart on my part.)
- Bryan
Sent
On Thu, Aug 20, 2009 at 1:37 PM, Kyle Sluderkyle.slu...@gmail.com wrote:
P: Two objects are equal.
Q: They have the same hash.
P - Q.
Note that Q does not imply P.
Or said another way...
If the hash of ObjectA is equal to the hash of ObjectB then ObjectA
_could_ be equal to ObjectB. If
On Thu, Aug 20, 2009 at 1:37 PM, Kyle Sluderkyle.slu...@gmail.com wrote:
On Thu, Aug 20, 2009 at 1:33 PM, Clark Coxclarkc...@gmail.com wrote:
-isEqual: is how Cocoa collections define equality. Saying that two
objects are equal means, by definition, that -[obj1 isEqual: obj2]
returns true.
On Thu, Aug 20, 2009 at 1:47 PM, Shawn Ericksonshaw...@gmail.com wrote:
On Thu, Aug 20, 2009 at 1:37 PM, Kyle Sluderkyle.slu...@gmail.com wrote:
P: Two objects are equal.
Q: They have the same hash.
P - Q.
Note that Q does not imply P.
Or said another way...
If the hash of ObjectA is
On Thu, Aug 20, 2009 at 2:01 PM, Clark Coxclarkc...@gmail.com wrote:
Yes, and two different objects will have different pointer values. If
the hash is based on the pointer values, then two different objects
cannot have the same hash, regardless of whether or not they are
equal. Hence, that
On Thu, Aug 20, 2009 at 2:14 PM, Kyle Sluderkyle.slu...@gmail.com wrote:
On Thu, Aug 20, 2009 at 2:01 PM, Clark Coxclarkc...@gmail.com wrote:
Yes, and two different objects will have different pointer values. If
the hash is based on the pointer values, then two different objects
cannot have
On Aug 20, 2009, at 12:00 PM, Seth Willits wrote:
From the docs:
If a mutable object is added to a collection that uses hash values
to determine the object’s position in the collection, the value
returned by thehash method of the object must not change while the
object is in the
On 20 Aug 2009, at 22:16, Clark Cox wrote:
On Thu, Aug 20, 2009 at 2:14 PM, Kyle Sluderkyle.slu...@gmail.com
wrote:
On Thu, Aug 20, 2009 at 2:01 PM, Clark Coxclarkc...@gmail.com
wrote:
Yes, and two different objects will have different pointer values.
If
the hash is based on the pointer
Yup, and my mistake in the suggestion :). Probably juggling too many
balls int he air again today...
On Aug 20, 2009, at 2:16 PM, Clark Cox wrote:
I thought we were talking about -hash just returning zero?
--Kyle Sluder
No, we were talking about:
It is, but you can generally do better
OK, so this discussion is getting a little crazy :-)
Agreed.
The -hash method is important for objects that are used as keys in
associative collections.
[snip]
So, in practice, it's perfectly safe in 99.9% of cases to base your
hash off your object's properties. In the specific case when
On Aug 20, 2009, at 2:31 PM, Alastair Houghton wrote:
The -hash method is important for objects that are used as keys in
associative collections. So the worry about the hash value changing
when an object's properties are altered is a bit of a red herring,
because you *aren't supposed to
The -hash method is important for objects that are used as keys in
associative collections.
[snip]
So, in practice, it's perfectly safe in 99.9% of cases to base your
hash off your object's properties. In the specific case when you're
mutating objects that are keys in associative collections
Core Data doesn't use random objects as keys in dictionaries or sets
for this reason. It's not that we don't trust you, but ... to
prevent misunderstandings, all NSManagedObject subclasses are
forbidden from overriding -hash and -isEqual.
I have to admit, I didn't know this bit but I see it
On Thu, Aug 20, 2009 at 9:09 PM, Jeff Laingjeff.la...@spatialinfo.com wrote:
Core Data doesn't use random objects as keys in dictionaries or sets
for this reason. It's not that we don't trust you, but ... to
prevent misunderstandings, all NSManagedObject subclasses are
forbidden from
On Aug 20, 2009, at 20:51, Seth Willits wrote:
On Aug 20, 2009, at 2:31 PM, Alastair Houghton wrote:
The -hash method is important for objects that are used as keys in
associative collections. So the worry about the hash value
changing when an object's properties are altered is a bit of a
Separately, collections may (and presumably sometimes do) use *object*
hash values to distribute objects in memory. (Obviously, NSSet does,
and for all we know NSDictionary does too, to distribute object values
that stored under the same key hash value -- though it would be an
implementation
On Aug 20, 2009, at 9:44 PM, Quincey Morris wrote:
The keys in a dictionary (or other keyed collection, like a map
table) need to be immutable objects, but that's unrelated to the
hash. Mutability in the keys would be bad, hash or no hash.
What do you mean by immutable? You can put a
On Aug 20, 2009, at 22:05, Jeff Laing wrote:
Without wanting to keep the thread going forever, can I just ask why
we would presume this?
In fact, if I were implementing NSDictionary I'd assume the reverse,
that I was not allowed to assume that an objects hash would not
change.
Is there
I was just looking up the documentation to remind myself of the
difference between isEqual: and isEqualTo: and saw that for your own
custom objects to behave nicely in a collection, it apparently needs
to override both isEqual: and hash.
But when I look at the specific documentation for
On Wed, Aug 19, 2009 at 4:28 PM, Gideon Kinggid...@novamind.com wrote:
So do I need to override hash too? If so, are there any recommendations as
to how to determine the hash easily?
You need to override -hash for the simple reason that the
documentation says you need to override -hash. That
On Aug 19, 2009, at 4:28 PM, Gideon King wrote:
So do I need to override hash too? If so, are there any
recommendations as to how to determine the hash easily?
If you need to override -isEqual: to provide something besides pointer
comparison, you should also override -hash. If objects are
On Aug 19, 2009, at 4:28 PM, Gideon King wrote:
So do I need to override hash too? If so, are there any
recommendations as to how to determine the hash easily?
Sorry, just came across this thread that has some more tips:
Excellent, thanks for that - in my case I only have up to about a
dozen objects in my array, so I'll just return 0 for the hash and let
it fall back to isEqual:. I see that some of the Omni classes do that
too...
In other cases where I make few changes but do lots of comparisons, I
might
On Aug 19, 2009, at 4:28 PM, Gideon King wrote:
So do I need to override hash too? If so, are there any
recommendations as to how to determine the hash easily?
I probably shouldn't admit this, but I've yet to override hash and
have yet to notice any problems. The docs say I should, so I
I see your point, and I have been writing Obj-C code since 1991 and
don't recall ever having written a hash method, and it's never bitten
me before.
...but I believe Kyle's point is very valid. The documentation is very
explicitly saying that you should implement it, so if you don't then
On Aug 19, 2009, at 6:19 PM, Seth Willits wrote:
On Aug 19, 2009, at 4:28 PM, Gideon King wrote:
So do I need to override hash too? If so, are there any
recommendations as to how to determine the hash easily?
I probably shouldn't admit this, but I've yet to override hash and
have yet to
Seth Willits wrote:
On Aug 19, 2009, at 4:28 PM, Gideon King wrote:
So do I need to override hash too? If so, are there any
recommendations as to how to determine the hash easily?
I probably shouldn't admit this, but I've yet to override hash and have
yet to notice any problems. The
On Wed, Aug 19, 2009 at 6:19 PM, Seth Willitssli...@araelium.com wrote:
On Aug 19, 2009, at 4:28 PM, Gideon King wrote:
So do I need to override hash too? If so, are there any recommendations as
to how to determine the hash easily?
I probably shouldn't admit this, but I've yet to override
On Aug 19, 2009, at 6:17 PM, Gideon King wrote:
In other cases where I make few changes but do lots of comparisons,
I might use the string hash idea and cache the return value in the
object, triggering an update whenever the relevant data changes.
This would be easy for me because the
50 matches
Mail list logo
