I didn’t realize that I was saying anything controversial. On Aug 11, 2016, at 01:50 , Britt Durbrow <bdurb...@rattlesnakehillsoftworks.com> 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 <d...@looktowindward.com> 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 <admin.szatmari....@gmail.com> 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. > 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 (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
