On 09/08/2012, at 5:31 PM, Quincey Morris <quinceymor...@rivergatesoftware.com> wrote:
>> So call super, but you need to know whether it's going to call through your >> -init method or not (for cells, it does not). > > Except that you do sort-of know (I think). If it does, all your instance > variables are 0. If you have object-pointer instance variables that aren't > nil after calling super, then (I think) you can assume that a superclass used > NSCopyObject. Not necessarily. For cells that might be OK since mostly a cell subclass's -init methods are probably fairly simple, but suppose your subclass has a mutable array for example, and you assign it to be an empty array in -init. Your copy method can't tell by looking at that ivar whether it was copied or created new... I suppose it could check whether the pointer value was equal in the copy, knowing that the -init method assigns a new instance... but while that avoids the flag hack, it's still pretty stinky. > But thinking about Greg's comments earlier in the day, I have started to > believe that NSCopyObject isn't in itself a problem. I think the problem is > really that you don't know whether the ARC compilation mode of the superclass > is the same as the ARC compilation mode of your subclass. > > There's a workaround (or no need of a workaround) for every combination of > super/subclass mode. It's that you don't know which workaround to use (or not > use) unless you know whether ARC was on or off when the superclass was > compiled. Yes, I think you've put your finger on it. For the case of NSCell, I now know how it currently behaves and can take that into account for copy methods. It's documented, albeit obscurely, and as Greg says, it's probably going to tie Apple's hands on binary compatibility unless some wholesale change is made to the API for copying. (As the Obj-C language gradually gets extended, maybe we could even get something like C++ copy constructors, only hopefully better). But trying to generalise the NSCell situation to any subclassable Cocoa class, where you just don't know whether super will use NSCopyObject() with or without ARC enhancements, or alloc/init, it's looking pretty difficult to come up with a general rule about how to correctly implement copy. But perhaps the situation isn't that bad - I haven't run into this very widely, and as NSCopyObject is now deprecated it may only remain an issue for very old classes such as NSCell, and it can be documented as a special case. --Graham _______________________________________________ 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
