> Hmm… I’m not so sure that this is *quite* right… what if I want a copy of the > original object, with the same creation date? Not doing so could lead to some > strange pitfalls, depending on what is then done with the alleged “copy”, and > how it reacts to other methods (like -hash and -isEqual, or any sort of > serialization methods it implements).
Well you have to write a copy method so you can do whatever you want either keep the same creation date or change it. > "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.” (emphasis mine) it’s up to you (or the class) to decide what a “copy” means, but the Cocoa classes that support copying define their own version of what a copy is. Don’t forget there are two ways to test that two objects are “Equal”, object1 == object2 //Exactly the same object as so by definition Equal [object1 isEqual:object2] //Functionally Equal So in the case of the creation date, isEqual would not check the date property in the comparison if it didn’t matter….. > Which, IMHO, means that *all* the values stored in the object must be the > same. 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). All the Best Dave > On 11 Aug 2016, at 09:50, Britt Durbrow > <bdurb...@rattlesnakehillsoftworks.com> wrote: > > >> On Aug 11, 2016, at 12:04 AM, Quincey Morris >> <quinceymor...@rivergatesoftware.com> wrote: >> >> 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. > > Hmm… I’m not so sure that this is *quite* right… what if I want a copy of the > original object, with the same creation date? Not doing so could lead to some > strange pitfalls, depending on what is then done with the alleged “copy”, and > how it reacts to other methods (like -hash and -isEqual, or any sort of > serialization methods it implements). > > From the documentation: > > "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.” (emphasis mine) > > 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. > > For the case of an immutable object, those conditions are indeed fulfilled by > simply returning self; because by definition an immutable object and a copy > of an immutable object at a different memory address would behave the same, > forever. Returning self is, in this case, just an implementation detail (an > optimization, specifically). > > It is, however, perfectly valid (if not encouraged for performance and memory > use reasons) to actually create a new object, with all the same values as the > original. > > > At a higher level, instead of having -copy return an object that was *almost* > a copy; I think I would (if possible) refactor the problem to put that > information somewhere else… or better yet, don’t do that at all (and given > that copies come and go; I don’t think that non-invariant metadata like that > is going to do what is usually desired, in the broader sense of solving the > problem at hand; whatever problem it may be). > _______________________________________________ > > 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/dave%40looktowindward.com > > This email sent to d...@looktowindward.com _______________________________________________ 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
