> 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
> <quinceymor...@rivergatesoftware.com> 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 (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
