Re: RFC: Non-fragile ivars

[Michael Ash]

hns@computer.org <hns@computer.org> wrote:
> On 3 Jun., 15:47, Michael Ash <m...@mikeash.com> wrote:
>> Saso Kiselkov <skisel...@gmail.com> wrote:
>> > It would be great to also add this algorithm into +poseAsClass: and
>> > possibly category handling, since that would allow to have posing
>> > classes and categories define their own ivars.
>>
>> You have to be really careful with this because you can't have any
>> existing instances of the class in question when you make such a
>> modification. If there are already objects floating around then a lot of
>> bad things happen. This will work fine if you load categories at launch or
>> explicitly pose before creating objects, but normally these two operations
>> have been safe to perform at will. I assume that this is at least part of
>> the reason why Apple doesn't allow declaring ivars in categories even with
>> their new shiny runtime.
> 
> Ah, this may be the reason why class posing is no longer available in
> Obj-C 2.0 and the new Apple Runtime (but for 64 bit mode only!)...
> 
> http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/NSObject_Class/DeprecationAppendix/AppendixADeprecatedAPI.html
> 
> "Posing is deprecated in Mac OS X v10.5. The poseAsClass: method is
> not available in 64-bit applications on Mac OS X v10.5."
> 
> http://developer.apple.com/releasenotes/Cocoa/RN-ObjectiveC/index.html#//apple_ref/doc/uid/TP40004309-DontLinkElementID_10
> 
> "All instance variables in 64-bit Objective-C are non-fragile."

Posing already required the posing class not to declare new instance 
variables, though. They could have carried that requirement through to 
64-bit. I'm not really sure why they eliminated it other than that it's 
"ugly". The same capabilities are still present, through the use of 
"method swizzling" which is supported through a new runtime function so 
that the programmer doesn't have to write a bunch of buggy code to do it 
manually.

> But: where do we really need class posing (although I like the
> concept)?

Mostly I've found it to be useful for debugging. You can override a method 
of a class you don't own to find out where it gets called, log additional 
information, etc. Particularly useful when you need to track down a bug on 
a user's machine and they're not handy with gdb.

It can also be useful for fixing problems in classes you don't own. 
Here's a case of where I describe a way to fix the odd behavior of 
+cellClass for nib-loaded NSControl subclasses:

http://www.mikeash.com/?page=pyblog/custom-nscells-done-right.html

By posing a custom subclass as NSControl, a single fix can be used instead 
of duplicating code throughout all custom subclasses. Of course caution 
must be exercised because if there's any other code in your process which 
depends on the "buggy" behavior then you're sunk.

-- 
Mike Ash
Radio Free Earth
Broadcasting from our climate-controlled studios deep inside the Moon