Uli's Web Site
[ Zathras.de - Uli's Web Site ]
Other Sites: Stories
Pix
Abi 2000
Stargate: Resurgence
Lost? Site Map!
 
 
     home | blog | moose | programming | articles >> blog

 Blog
 
 Archive
 
 Blog Topics
 

15 Most Recent [RSS]

 Less work through Xcode and shell scripts
2011-12-16 @600
 
 iTunesCantComplain released
2011-10-28 @954
 
 Dennis Ritchie deceased
2011-10-13 @359
 
 Thank you, Steve.
2011-10-06 @374
 
 Cocoa Text System everywhere...
2011-03-27 @788
 
 Blog migration
2011-01-29 @520
 
 All you need to know about the Mac keyboard
2010-08-09 @488
 
 Review: Sherlock
2010-07-31 @978
 
 Playing with Objective C on Debian
2010-05-08 @456
 
 Fruit vs. Obst
2010-05-08 @439
 
 Mixed-language ambiguity
2010-04-15 @994
 
 Uli's 12:07 AM Law
2010-04-12 @881
 
 Uli's 1:24 AM Law
2010-04-12 @874
 
 Uli's 6:28 AM Law
2010-04-12 @869
 
 Uli's 3:57 PM Law
2010-04-12 @867
 

More...

Method Swizzling considered harmful

There's a technique in Cocoa called "method swizzling". In principle, it lets you rename a method in one class and create a new one in its place by swapping the two methods' implementations. This is very useful when you want to place a category on a system class to replace a method, but you still want to be able to call the original method.

For a long time, people have been using the Method Swizzling sample code on CocoaDev. However, that piece of code had a big problem: It replaced the method, even if it was inherited from a superclass. On the other hand, your new method (which contained the old code) was only available in your subclass. So, by swizzling, you could accidentally inject your code at too high a level. Some people tried to just add if( [self class] == [NSSuperclass class] ), but of course that was unable to find the swizzled method with the original implementation, because that was in your subclass. Ouch.

Moreover, if you were swizzling someone else's class (and that was after all the main use: To modify system classes), all it took to break your code, even if it worked, was for that other person to move a method up in the class hierarchy, which is not an uncommon occurrence during refactoring.

The solution was to check at runtime for the case where a method is inherited from the superclass and instead of swizzling it there, to add a method at runtime that simply calls through to super. Once that is done, you have a method at the right level to swizzle safely.

Looks like Kevin Ballard came up with a safe and working implementation of method swizzling. Thanks, Kevin!

Reader Comments: (RSS Feed)
No comments yet
Comment on this article:
Name:
E-Mail: (not shown, hashed for Gravatar)
Web Site URL: (optional)
Comment: (plain text only)
Please Enter the following word:
Or E-Mail Uli privately.

 
Created: 2007-04-05 @956 Last change: 2007-04-05 @987 | Home | Admin | Edit
© Copyright 2003-2014 by M. Uli Kusterer, all rights reserved.