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: Britt Durbrow <email@hidden>
- Date: Thu, 11 Aug 2016 16:21:01 -0700
> I didn’t realize that I was saying anything controversial.
Oh, it’s usually the most innocuous seeming of things that ignite the biggest firestorms… :-)
> On Aug 11, 2016, at 11:11 AM, Quincey Morris <email@hidden> wrote:
>
> “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.
Hmm… at the risk of being accused of splitting hairs here… *how* it’s stored in the object is the implementation detail, that it *is* stored in it is what matters (where by the definition of “stored in it” means that you can access it via an accessor or instance variable; I am deliberately not considering stuff like associated metadata that physically resides in an otherwise unattached location to be "stored in it", because doing so makes the underlying assumptions of object identity and boundaries start to break down).
> AFAIK, the only constraint is the one documented in the NSCopying protocol, which was already quoted in this thread:
If your object conforms to the NSObject protocol, then that does impose additional restrictions. If it doesn’t, then all bets are off; as it’s totally outside of the scope of the Cocoa frameworks (i.e, it descends from some other non-NSObject root object).
>> 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.
>
I generally don’t consider things done for debugging purposes in these sorts of discussions, because there’s lots of nasty hacks that are done to elucidate why the system is not behaving as expected (for example, I happen to have open in Xcode at the moment a snippet that cracks NSUndoManager wide open, so I can see just what I did wrong - TOTALLY a no-no for production code!). Also, if you did do something like that, you’d probably make sure that hash and isEqual ignored it, so as not to upset the rest of the frameworks.
Ignoring the above caveat about debug stuff; in the specific example of the creation date; I don’t consider creating an object (for whatever reason) that has some property different than the original to be compliant with NSCopying’s requirement of "with values identical to the original at the time the copy was made”.
> 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.
>
Desirable, but not mandatory: I say it’s still legal to return [self retain]. However, FWIW, I will mention that tagged pointers are reserved for the exclusive implementation by Apple; and involve some serious Dark Magic (tm) deep in the runtime (i.e, it required the co-opting and co-operation of objc_msgSend).
> 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.
And considering how often things get copied in the Cocoa frameworks, that’s kinda’ a big deal optimization. :-)
________________________________________________________________________________________________
And from the next posting:
> 2. Since there is no *formal* distinction between mutable and immutable objects, there is no formal constraint on either of:
Yeah, Cocoa specification itself is kinda’ wishy-washy about that (probably for reasons of expediency and flexibility). However, if we accept the common definition of immutable as "that which cannot change”; then in combination with several other factors, it becomes evident that for all immutable objects you can just return [self retain]… here’s my logic:
Given that:
"a copy must be a functionally independent object with values identical to the original at the time the copy was made”;
by definition, an object is equal to itself;
"functionally independent” means that no matter what you do to the original, there will be no effects on the copy;
immutable objects by definition can’t change (otherwise they would be mutable objects);
objects that can’t change can’t have any effects put upon them, because any effect is by definition a change;
it follows that the original object, due to it’s immutability, is functionally independent to itself… and as a consequence of that, an immutable object is a valid copy of itself.
Therefore:
@implementation myImmutableClass
- (id)copyWithZone:(NSZone *)zone
{
return [self retain]; // non-ARC, obviously...
}
@end
is perfectly valid code. :-)
_______________________________________________
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