Re: copy & isEqual nightmares
Re: copy & isEqual nightmares
- Subject: Re: copy & isEqual nightmares
- From: James Maxwell <email@hidden>
- Date: Sun, 12 Feb 2012 17:54:02 -0800
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 (email@hidden)
>>>
>>> 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:
>>>
>>> This email sent to email@hidden
>>
>> ------------------------------------------------------
>> James B. Maxwell
>> Composer/Researcher/PhD Candidate
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> Cocoa-dev mailing list (email@hidden)
>>
>> 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:
>>
>> This email sent to email@hidden
>
------------------------------------------------------
James B. Maxwell
Composer/Researcher/PhD Candidate
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden