Re: copy & isEqual nightmares

On Feb 17, 2012, at 8:51 PM, Ken Thomases wrote: > On Feb 17, 2012, at 2:33 PM, Ben Kennedy wrote: > >> On 16 Feb 2012, at 3:54 pm, Ken Thomases wrote: >> >>> In other words, you're being silly. It's clear to everyone that -[NSString >>> isEqual:] must have semantics built on -[NSString isEqua

Re: copy & isEqual nightmares

On Feb 17, 2012, at 2:33 PM, Ben Kennedy wrote: > What value does NSString's isEqualToString: bring to the table over its > implementation of isEqual? Is it just a matter of foregoing an 'if ([obj > isKindOfClass:[NSString class])' construct at the front end? Put another > way, why does NSStr

Re: copy & isEqual nightmares

On Feb 17, 2012, at 2:33 PM, Ben Kennedy wrote: > On 16 Feb 2012, at 3:54 pm, Ken Thomases wrote: > >> In other words, you're being silly. It's clear to everyone that -[NSString >> isEqual:] must have semantics built on -[NSString isEqualToString:], which >> is clearly documented. > > What va

Re: copy & isEqual nightmares

Le 17 févr. 2012 à 21:33, Ben Kennedy a écrit : > On 16 Feb 2012, at 3:54 pm, Ken Thomases wrote: > >> In other words, you're being silly. It's clear to everyone that -[NSString >> isEqual:] must have semantics built on -[NSString isEqualToString:], which >> is clearly documented. > > What v

Re: copy & isEqual nightmares

On 17 Feb 2012, at 20:33, Ben Kennedy wrote: > On 16 Feb 2012, at 3:54 pm, Ken Thomases wrote: > >> In other words, you're being silly. It's clear to everyone that -[NSString >> isEqual:] must have semantics built on -[NSString isEqualToString:], which >> is clearly documented. > > What valu

Re: copy & isEqual nightmares

On 16 Feb 2012, at 3:54 pm, Ken Thomases wrote: > In other words, you're being silly. It's clear to everyone that -[NSString > isEqual:] must have semantics built on -[NSString isEqualToString:], which is > clearly documented. What value does NSString's isEqualToString: bring to the table over

Re: copy & isEqual nightmares

On Feb 16, 2012, at 3:47 PM, Quincey Morris wrote: > On Feb 16, 2012, at 11:44 , Ken Thomases wrote: > >> Well, the documentation for -[NSDictionary isEqualToDictionary:] >>

Re: copy & isEqual nightmares

On Feb 16, 2012, at 11:44 , Ken Thomases wrote: > Well, the documentation for -[NSDictionary isEqualToDictionary:] >

Re: copy & isEqual nightmares

On Feb 16, 2012, at 10:47 AM, Quincey Morris wrote: > On Feb 16, 2012, at 08:30 , Ken Thomases wrote: > >> A dictionary is equal to any other dictionary with equal keys and values. >> That's true for a mutable dictionary, too. Mutating a mutable dictionary >> will changes which other objects

Re: copy & isEqual nightmares

On Feb 16, 2012, at 08:30 , Ken Thomases wrote: > A dictionary is equal to any other dictionary with equal keys and values. > That's true for a mutable dictionary, too. Mutating a mutable dictionary > will changes which other objects it's equal to. Really? Well, OK. I can't find any documen

Re: copy & isEqual nightmares

On Feb 15, 2012, at 11:39 AM, Quincey Morris wrote: > I was just acknowledging the difference between (say) a NSMutableDictionary > whose internal state changes over time without affecting the objects it's > isEqual to (just itself, in this case) [...] A dictionary is equal to any other diction

Re: copy & isEqual nightmares

On 16/02/2012, at 4:39 AM, Quincey Morris wrote: > There are, of course, potentially, objects that aren't isEqual to themselves. Surely the first thing that -isEqual: does is to trivially accept the case where self == otherObject? Certainly when I've implemented -isEqual: I do that as a matte

Re: copy & isEqual nightmares

This reminded me of this blog post, which you may find interesting: http://ridiculousfish.com/blog/posts/array.html Thanks, Jon On Feb 14, 2012, at 8:35 AM, Quincey Morris wrote: > NSDictionary may not use the value object hashes, but I don't see that > there's anything from preventing it from

Re: copy & isEqual nightmares

On Feb 15, 2012, at 00:50 , Uli Kusterer wrote: > Why would there ever be an object that is not -isEqual: to itself? Now you've > lost me. Sorry, it was a poor choice of words. I was just acknowledging the difference between (say) a NSMutableDictionary whose internal state changes over time wi

Re: copy & isEqual nightmares

On 14.02.2012, at 17:35, Quincey Morris wrote: > Yes, you're right, I rashly forgot to consider all the possibilities. There > is a kind of class whose instances are *not* (necessarily) isEqual to > themselves over time. I don't know that there's terminology for this -- > "mutable object" doesn'

Re: copy & isEqual nightmares

On Feb 14, 2012, at 04:32 , James Montgomerie wrote: > Take a mutable string as the canonical example - obviously its hash should > change when its contents changes (and it should no longer be isEqual: with a > copy of its older self). It's up to the user of the string to ensure that > they don

Re: copy & isEqual nightmares

On 13.02.2012, at 18:29, Quincey Morris wrote: > There are 3 points to take away, beyond the basic requirements: > > 1. "the value returned by the hash method of the object must not change…". It > sounded like you were contradicting this, above. No. Keep in mind, this restriction is with regard

Re: copy & isEqual nightmares

On 13 Feb 2012, at 17:29, Quincey Morris wrote: > It's a mistake to calculate the hash from *mutable* object state, including > ivars that "can be changed after creation". The NSObject protocol > documentation on 'hash' is worth recalling: > >> hash >> Returns an integer that can be used as a t

Re: copy & isEqual nightmares

On Feb 13, 2012, at 01:14 , Uli Kusterer wrote: > The hash should be calculated from your object's values. If your object's > ivars (those that are relevant to the hash) can be changed after creation, > you must always recalculate your hash whenever one of them is modified (or > mark it as inva

Re: copy & isEqual nightmares

oops, yes. typo (0x%X) J. On 2012-02-13, at 1:21 AM, Uli Kusterer wrote: > On 13.02.2012, at 02:54, James Maxwell wrote: >> NSLog(@"%@", [obj hash]) > > I hope this is a typo. %@ expects an object, while -hash returns an integer. > If you're lucky, this will crash, or just output garbage. Your

Re: copy & isEqual nightmares

On 13.02.2012, at 02:54, James Maxwell wrote: > NSLog(@"%@", [obj hash]) I hope this is a typo. %@ expects an object, while -hash returns an integer. If you're lucky, this will crash, or just output garbage. Your compiler should be warning you about that line. Cheers, -- Uli Kusterer "The Witn

Re: copy & isEqual nightmares

On 13.02.2012, at 01:25, James Maxwell wrote: > But what I don't get is how hash plays into all this. I've always read that I > have to override hash when I override isEqual, but I don't exactly understand > what that means or does. What I've done is to make a hash that is equal when > two objec

Re: copy & isEqual nightmares

On Feb 12, 2012, at 7:37 PM, Ken Thomases wrote: > There shouldn't be much mystery about how to implement object copying since > Apple documents it pretty clearly... Er, holy crap! I went to find the > article titled "Implementing Object Copy" and Apple seems to have deleted it > from the refe

Re: copy & isEqual nightmares

okay, that's getting to the root of the problem. Never knew about %p... yikes! Good to know. Thanks! J. On 2012-02-12, at 6:22 PM, Graham Cox wrote: > > On 13/02/2012, at 12:54 PM, James Maxwell wrote: > >> But it does beg the question: is there an easy way to test the **identity** >> of an

Re: copy & isEqual nightmares

On 13/02/2012, at 11:54 AM, James Maxwell wrote: > But it does beg the question: is there an easy way to test the **identity** > of an object? That is, to NSLog the identity of an object, to see if (and > how) it's different to a copy that returns YES to isEqual and has the same > hash? I gues

Re: copy & isEqual nightmares

On 13/02/2012, at 12:54 PM, James Maxwell wrote: > But it does beg the question: is there an easy way to test the **identity** > of an object? That is, to NSLog the identity of an object, to see if (and > how) it's different to a copy that returns YES to isEqual and has the same > hash? Look

Re: copy & isEqual nightmares

Yes, thanks Ken. I've sorted out the copying issue I **thought** I was having. Turned out not to be a copying issue (and my isEqual and hash were fine, which I kind of suspected)... my data was getting pooched somewhere else. I was just confused because I had naively placed an NSLog(@"%@", [ob

Re: copy & isEqual nightmares

Both of the code snippets on that StackOverflow thread have bugs if you're manually managing memory (as opposed to using GC or ARC). Since they use the dot syntax to set the property of the copy, they are invoking the setter. In all probability, the setter does memory management. It takes own

Re: copy & isEqual nightmares

On Feb 12, 2012, at 16:25 , James Maxwell wrote: > I have an object with isEqual set up to help me limit the number of "unique" > objects I can put in a Dictionary. Basically, the object has a few properties > which account for "equality", and some properties that don't matter. For > example, p

Re: copy & isEqual nightmares

On 13/02/2012, at 11:44 AM, James Maxwell wrote: > Okay, just saw an interesting post on this: > > http://stackoverflow.com/questions/1459598/how-to-copy-an-object-in-objective-c > > This is quite different from what I've generally seen, which just does: > > MyClass* copy = [[self class] alloc

Re: copy & isEqual nightmares

Okay, just saw an interesting post on this: http://stackoverflow.com/questions/1459598/how-to-copy-an-object-in-objective-c This is quite different from what I've generally seen, which just does: MyClass* copy = [[self class] allocWithZone:zone]; then uses accessors to assign all the properties

copy & isEqual nightmares

Okay, so I'm officially confused. I have an object with isEqual set up to help me limit the number of "unique" objects I can put in a Dictionary. Basically, the object has a few properties which account for "equality", and some properties that don't matter. For example, propA and propB are used