Re: Creating the app menu from scratch
Re: Creating the app menu from scratch
- Subject: Re: Creating the app menu from scratch
- From: Bill Bumgarner <email@hidden>
- Date: Mon, 14 Jul 2008 01:16:24 -0700
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.
b.bum
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.
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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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