On Jul 13, 2008, at 11:35 PM, Jeff Johnson wrote:
On Jul 13, 2008, at 10:37 PM, Bill Bumgarner wrote:And, no, exchanging class methods is not a typical pattern to be employed when developing a Cocoa application. In particular, replacing or exchanging method implementations found in Apple frameworks is completely unsupported and will quite likely break in the future.I fully admit that the use of the private methods -[NSApplication setAppleMenu:] and -[NSMenu _setMenuName:] is completely unsupported and may break in the future, though I hope that they don't and that in fact Apple provides public API for this functionality.b.bum
Any time you use private API, it isn't just that it might go away, it might change behavior or may change prerequisites or may have different side effects, etc...
On the other hand, the function method_exchangeImplementations() just became public API in Leopard, so I don't see how that can break anytime soon. It's not much different than subclassing or 'categorizing'.
Correct. However, it is what you are using method_exchangeImplementations() for that is problematic. Namely, you are editing the method tables for an Apple supplied class. This is unsupported and may be problematic for any number of reasons -- KVO, IMP caching, internal implementation details, etc...
It is quite a bit different than either subclassing or using categories.For subclassing, you override behavior and, if you are doing it right, don't break encapsulation -- don't access your super's instance variables directly and do use API to manipulate super's state (unless, of course, super is actually a class of your own design -- then it is all fair game, but you should still consider carefully how the super/ sub relationship should be work).
For categories, all is well until the moment you override an existing method in a class other than your own. At that point, you are asking for a world of maintenance headaches and a whole lot of fun debugging stuff.
b.bum
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Cocoa-dev mailing list ([email protected]) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
