On May 18, 2015, at 15:51 , Mike Abdullah <[email protected]> wrote: > > It’s just the way it is.
That was my first reaction, too, but there’s a nasty problem if the default implementation produces an object of the wrong class, which it does in this case. > I figure ‘twould be a whole heap of mess if the compiler were to somehow > become aware that the property type is a mutable object, and so therefore > needs to me mutably copied instead. I’m not sure this is really such a big heap o’ mess. In here: https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/EncapsulatingData/EncapsulatingData.html <https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/EncapsulatingData/EncapsulatingData.html> there’s this note: > Note: Any object that you wish to set for a copy property must support > NSCopying, which means that it should conform to the NSCopying protocol. If that’s true, then the rule could be that if it (that is, the property’s class, not the value’s class) supports NSMutableCopying a mutableCopy occurs, otherwise if it supports NSCopying, a copy occurs. IAC, at risk of offending Jens’s colleague, I’d say the real problem is that specifying a mutable object as a property value is fraught with difficulties, and asking for a copy of a mutable object makes things so much worse — there’s no natural definition of “copy” here. (Deep or shallow? It depends. Mutable or immutable? It depends.)
_______________________________________________ Do not post admin requests to the list. They will be ignored. Objc-language mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/objc-language/archive%40mail-archive.com This email sent to [email protected]
