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: Sandor Szatmari <email@hidden>
- Date: Thu, 11 Aug 2016 15:50:08 -0400
Quincey,
Thanks for you additional thoughts...
> On Aug 11, 2016, at 14:11, Quincey Morris <email@hidden> wrote:
>
> I didn’t realize that I was saying anything controversial.
>
>> On Aug 11, 2016, at 01:50 , Britt Durbrow <email@hidden> wrote:
>>
>> Which, IMHO, means that *all* the values stored in the object must be the same.
>>
>> By extension; [anObject hash] and [[anObject copy] hash] must return the same value; and [anObject isEqual:[anObject copy]] must return YES.
>
>
> “Stored in” is incorrect. What’s stored is an implementation detail. It’s only the outward-facing values that matter. I believe your extension is also technically false. See below.
>
>> On Aug 11, 2016, at 04:22 , Dave <email@hidden> wrote:
>>
>> All non-object values should be identical, objects should be *functionally* identical (and *you* define what functional means, if you need the same creation date in one class and a new one in another that’s ok, they function differently).
>
> Or they function the same. If I added the creation date solely as something to look at in the debugger, the object and its copy are still functionally identical as far as the app is concerned.
>
>> On Aug 11, 2016, at 05:48 , Sandor Szatmari <email@hidden> wrote:
>>
>> 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:.
>
> AFAIK, the only constraint is the one documented in the NSCopying protocol, which was already quoted in this thread:
>
>> "The exact meaning of “copy” can vary from class to class, but a copy must be a functionally independent object with values identical to the original at the time the copy was made.”
>
>
> The thing is, this isn’t much of a constraint, because there’s no restriction on how tightly to interpret “identical” and “values”. In particular, AFAIK there is no *formal* requirement that the copy have the same hash, or satisfy ‘isEqual:' with its original. However, if copies aren’t ‘isEqual:’ to the original, they can’t usefully work as NSDictionary keys, so this may be a pragmatic, informal requirement, at least for utility classes.
I guess the answer is that the creation date property is not considered part of the 'meaning' of what the object is, and therefore would not be factored in when writing the -hash or -isEqual: methods. This is perfectly reasonable, as many objects have properties that do not contribute in answering the question, is this object functionally equivalent. I might have mistakenly promoted the creation date property in your example, giving it more import than it should have had. Thanks for furthering the discussion.
Sandor
>
>> Are there any real world examples of this in the Cocoa flora of objects?
>
>
> My example of an object that carries around its own creation date for debugging purposes isn’t exactly an unreal world example.
>
> Here’s another not-impossible scenario:
>
> If you copied a NSNumber or NSString instance that happened not to be a tagged pointer, but could be, it might be desirable for the ‘copy’ method to detect the situation and return a tagged pointer.
>
> Finally, the point of copy-by-incrementing-the-reference-count behavior is *not* to make copying of objects practically free. The point is to make *a copy of a copy* practically free. We often don’t know what object we’re copying in the first place (we might be passed a NSString* parameter, but it might actually be a NSMutableString instance), so the original copy might be expensive.
>
> _______________________________________________
>
> 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
_______________________________________________
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