[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On 3 Jun., 15:47, Michael Ash <[EMAIL PROTECTED]> wrote: >> Saso Kiselkov <[EMAIL PROTECTED]> 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 _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
