Re: Mutable and immutable class cluster implementation / "method swizzling" question
Re: Mutable and immutable class cluster implementation / "method swizzling" question
- Subject: Re: Mutable and immutable class cluster implementation / "method swizzling" question
- From: Greg Parker <email@hidden>
- Date: Fri, 25 Mar 2011 12:24:32 -0700
On Mar 24, 2011, at 9:49 PM, John Engelhart wrote:
> I'm not 100% certain that the from / to MetaClass bits are needed as they
> are probably redundant / unnecessary with the later class_getClassMethod /
> class_getInstanceMethod calls (i.e., they probably automatically do the
> exact same meta class checks).
class_getInstanceMethod(cls) is defined as class_getClassMethod(object_getClass(cls)).
> I am using class_replaceMethod, which for now isn't a problem since I'm
> assuming a "modern" 10.5+ runtime. I can't find a handy reference for the
> minimum version of iOS that this function is supported (I'm sort of assuming
> "all" as it started as a "modern" objc abi). If, for some reason, < 10.5 /
> "modern" ObjC run time support is required, I suppose I could hack up
> class_replaceMethod equivalent behavior, but this isn't a pressing issue
> right now.
iOS 2.0+ (i.e. all iOS since the introduction of the SDK) supports the modern runtime.
> Anyone from Apple want to comment on how kosher this is likely to be for an
> iOS / iPhone / iPad app? I ask because the three20 framework started to
> cause rejections due to its use of method swizzling. However, in the
> three20 case, they were clearly doing something that was borderline
> questionable (I think they swizzled -dealloc of -UIView or something to
> their own -dealloc replacement to hack in behavior?). I'm not doing
> anything like that, it's a fairly legitimate (at least, IMHO) use of
> swizzling, and I'm only swizzling over the immutable methods that I've
> written code for- I'm not overriding / swizzling the NSArray /
> NSMutableArray methods at all- the swizzling only happens to my (mutable)
> classes methods.
As I understand it, swizzling your own classes and methods is allowed, but swizzling to replace system methods is not.
> Can anyone think of corner cases in which these would not behave
> "identically" to their respective concrete Cocoa versions?
One edge case of copying methods from one class to another is calls to [super ...]. The super dispatch will be directed to the superclass of the class that originally implemented the method. If the original class and the copied-to class do not have the same superclass, you will get unexpected results in the copied-to class.
--
Greg Parker email@hidden Runtime Wrangler
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden