Re: Objective-C basics - (Why NSNumber conforms to NSCopying protocol)
Re: Objective-C basics - (Why NSNumber conforms to NSCopying protocol)
- Subject: Re: Objective-C basics - (Why NSNumber conforms to NSCopying protocol)
- From: Greg Weston <email@hidden>
- Date: Thu, 11 Aug 2016 15:22:17 +0200
>> 2. The fact than an object is immutable does not (in general) mean that a copy can be represented by the same object reference. For example, an object that contained its own date of creation might be immutable, but a copy might have a different date, and therefore be a different object. Putting this another way, the immutability does not make NSCopying conformance irrelevant.
>
> Are there any real world examples of this in the Cocoa flora of objects? If you had asked me before reading your response I would have called the behavior you describe a bug. I would have said the result of -copy on an object should have the same -hash and return true for -isEqual:.
The fact that internal instance variables are not identical does not mean that hash and isEqual cannot work as intended. It would only be a bug if the contract is broken. That's the point of requiring functional identity rather than strict identity.
Whether there are real examples of this in Cocoa is hard to say, because we're talking inherently about things that aren't part of a class' interface.
_______________________________________________
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