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." But: where do we really need class posing (although I like the concept)? -- hns _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
