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(@"%@", [obj hash]) in my code to test whether the object was a copy.... Doh!!! I knew, from my own implementation that the object could be a copy but still have the same hash!
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 guess I could put something in -description: that would tell me (i.e., include info on the data that I'm NOT comparing in my isEqual method)... Anyway, I was just curious about that. J. On 2012-02-12, at 5:37 PM, Ken Thomases wrote: > 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 ownership of > the object returned by the [obj copyWithZone: zone] expression, but that > expression already returned ownership, and nobody balanced or will balance > that. > > 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 reference library. That's a big problem. I've filed documentation > feedback and everybody else interested should, too. > > I still have it in Xcode 3.2.x in the Mac OS X 10.6 Core Library. You should > be able to add that docset to Xcode 4.x, too. If it's not offered directly, > you should be able to add it using its URL > <http://developer.apple.com/rss/com.apple.adc.documentation.AppleSnowLeopard.atom>. > In there, it's in the Memory Management Programming Guide. > > If somebody knows an easier place to find it, please post. > > Anyway, with respect to your original post, neither -isEqual: nor -hash has > any influence on copying, unless you deliberately inject such concerns into > your own implementation of copying. On the other hand, it would be quite > common for a copy to compare equal to the original and thus have the same > hash, but you seem clear on that. > > Regards, > Ken > > On Feb 12, 2012, at 6:44 PM, 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] allocWithZone:zone]; >> >> then uses accessors to assign all the properties, and returns the copy. >> >> But does that just give me a shallow copy? Do I really have to implement >> the version in the post -- that is, do I have to "call copyWithZone on all >> of [my] fields" to get a true, mutable copy, that doesn't muck with the >> original? I guess it makes sense, but I'm kind of surprised that the normal >> copy (i.e., the one I see everywhere) doesn't do that already, since that's >> what a "copy" seems to be, in the most general sense. (If I "copy" a paper >> document, I can burn the copy, write all over it, or whatever I want, >> without touching the original.) >> >> J. >> >> >> On 2012-02-12, at 4:25 PM, James Maxwell wrote: >> >>> 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 in isEqual, but propC isn't. >>> The point is that I can create a set with objects where only propA and >>> propB are different, and propC just is irrelevant. Maybe that seems weird, >>> but it's what I need. >>> >>> 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 objects have the same values for propA and propB >>> (ignoring propC). That's how I interpreted the few threads I've read about >>> overriding hash... >>> >>> But what I need to do in my code, right now, is to copy an object, then >>> alter some properties of the copy, but not the original -- a typical reason >>> for wanting a copy. But I'm seeing that the copy has the same hash and >>> appears to be the same object, since changing properties of the copy >>> changes the original. So does the system see the matching hashes as >>> identical objects, not just the collection classes? Do I have to manually >>> implement some sort of deepCopy method? Or, can I just change hash, so that >>> the copy is a different instance, without losing the functionality I need >>> for collections? I don't understand why I'd need to make a deepCopy, since >>> that's what copy is for... >>> >>> Any help greatly appreciated. >>> >>> J. >>> >>> >>> ------------------------------------------------------ >>> James B. Maxwell >>> Composer/Researcher/PhD Candidate >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >>> >>> Please do not post admin requests or moderator comments to the list. >>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >>> >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/cocoa-dev/jbmaxwell%40rubato-music.com >>> >>> This email sent to jbmaxw...@rubato-music.com >> >> ------------------------------------------------------ >> James B. Maxwell >> Composer/Researcher/PhD Candidate >> >> >> >> >> >> >> >> _______________________________________________ >> >> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >> >> Please do not post admin requests or moderator comments to the list. >> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >> >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/cocoa-dev/ken%40codeweavers.com >> >> This email sent to k...@codeweavers.com > ------------------------------------------------------ James B. Maxwell Composer/Researcher/PhD Candidate _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
