RE: swizzling a class to a subclass inorder to add ivars (& methods) to a class
RE: swizzling a class to a subclass inorder to add ivars (& methods) to a class
- Subject: RE: swizzling a class to a subclass inorder to add ivars (& methods) to a class
- From: "Michael Latta" <email@hidden>
- Date: Mon, 30 Oct 2006 09:30:55 -0800
They are making several changes in 64 bit to allow them more control over
the metadata which gives them more room for performance optimizations and
such. They are replacing all metadata structures with APIs and hiding the
implementation details (which is how it should be).
One of the outcomes of this is that when a superclass grows in size it does
not break subclasses that added ivars! No more need to reserve space for
future use.
Michael
> -----Original Message-----
> From: Mike Abdullah [mailto:email@hidden]
> Sent: Monday, October 30, 2006 9:16 AM
> To: Michael Latta
> Cc: email@hidden
> Subject: Re: swizzling a class to a subclass inorder to add ivars (&
> methods) to a class
>
> oh :(
>
> I can understand the reasoning (the whole process is a little
> dangerous for shipping apps), but for debugging purposes it can be
> damn handy!
>
> Mike.
>
> On 30 Oct 2006, at 16:53, Michael Latta wrote:
>
> > I just reviewed a WWDC session that indicated that poseAsClass: was
> > deprecated in 10.5 and would be going away. It may even be removed
> > in 64
> > bit in 10.5.
> >
> > Michael
> >
> >
> >> -----Original Message-----
> >> From: cocoa-dev-bounces+lattam=email@hidden
> >> [mailto:cocoa-dev-
> >> bounces+lattam=email@hidden] On Behalf Of Mike Abdullah
> >> Sent: Monday, October 30, 2006 12:55 AM
> >> To: Scott Morrison
> >> Cc: email@hidden
> >> Subject: Re: swizzling a class to a subclass inorder to add ivars (&
> >> methods) to a class
> >>
> >> Hi Scott, perhaps I'm being stupid here, but how about using
> >> poseAsClass: ?
> >>
> >> Mike.
> >>
> >> On 30 Oct 2006, at 04:08, Scott Morrison wrote:
> >>
> >>>
> >>> The mantra for categories and posed class is that you cannot add
> >>> ivars to a category or a posed class -- leaving you to fiddle with
> >>> mutable dictionarys and tablemaps to implement extra variables.
> >>> (ugh!)
> >>>
> >>> However, you can add ivars to a subclass -- so I got to thinking --
> >>> can you redirect an allocation for a class to a subclass so that
> >>> for all intents and purposes you can add ivars.
> >>>
> >>> In playing around, I found that by swizzling the classMethod: +
> >>> [NSObject alloc], you can redirect the allocation of a class to a
> >>> subclass as follows:
> >>> //------------------------------------------------------------------
> >>> --
> >>> --------------------------------------------------------------------
> >>>
> >>> @interface SubClass: AnyClass
> >>> {
> >>> NSString * extraIvar;
> >>> }
> >>>
> >>> @end
> >>>
> >>> static IMP oldAlloc = NULL;
> >>> @implementation NSObject (myCategory)
> >>> +(id) MYalloc{
> >>> id result;
> >>>
> >>> if(self == [AnyClass class]){
> >>> self = objc_getClass("SubClass"); //restate the class as the
> >>> subclass
> >>> result = NSAllocateObject(self,0,nil); // allocate the
> >> subclass
> >>> }
> >>> else
> >>> result = oldAlloc(self,_cmd);
> >>> return result;
> >>> }
> >>>
> >>> + (void) load {
> >>> oldAlloc = replaceClassMethod(@selector(alloc),self,@selector
> >>> (MYalloc),self); // standard class method swizzle the alloc method
> >>> of NSObject
> >>> }
> >>> //------------------------------------------------------------------
> >>> --
> >>> --------------------------------------------------------------------
> >>>
> >>>
> >>> One catch would be that any factory methods and any instance init
> >>> methods may have to be reproduced in the subclass if you want to
> >>> init your subclass ivars
> >>> eg.
> >>>
> >>> (id) init___:(id) anObject{
> >>> if ((self = [super init___:anObject])){
> >>> extraIvar = [[NSString alloc] initWithString:@"test iVar"];
> >>> }
> >>> return self;
> >>> }
> >>>
> >>>
> >>> Another catch would be that any test directly for an instance's
> >>> class type would fail (but tests for isKindOfClass: would be ok)
> >>>
> >>>
> >>> In anycase -- technically this is possible -- I have it working on
> >>> some test code
> >>>
> >>> However -- IS IT SAFE ?? -- if no -- why not ---
> >>> if "sorta" -- what are the gotchas and pitfalls?
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Do not post admin requests to the list. They will be ignored.
> >>> Cocoa-dev mailing list (email@hidden)
> >>> Help/Unsubscribe/Update your Subscription:
> >>> 40gmail.com
> >>>
> >>> This email sent to email@hidden
> >>
> >> _______________________________________________
> >> Do not post admin requests to the list. They will be ignored.
> >> Cocoa-dev mailing list (email@hidden)
> >> Help/Unsubscribe/Update your Subscription:
> >>
> >> This email sent to email@hidden
> >
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden