Re: Delegates -- WHAT is delegated? (was Re: Cocoa-dev Digest, Vol 3, Issue 1474)
Re: Delegates -- WHAT is delegated? (was Re: Cocoa-dev Digest, Vol 3, Issue 1474)
- Subject: Re: Delegates -- WHAT is delegated? (was Re: Cocoa-dev Digest, Vol 3, Issue 1474)
- From: Uli Kusterer <email@hidden>
- Date: Thu, 21 Dec 2006 10:15:33 +0100
Am 20.12.2006 um 22:14 schrieb Sam Colombo:
So the bottom line is that there is no sure way to identify
what is
delegatable from the supplied headers themselves. You have to
depend on the
occasional comments, protocols with "delegate" in their title, and
Notifications (or just look in the documentation) and take it on
faith that
they are actually delegatable. I guess I can live with that. (Like
I have a
choice. :-)
Yes. Though, of course, all of those *are* in the headers. :-p
There's nothing keeping you from creating your own view class that
delegates things if you want to. However, one advantage of delegation
is that you can implement the delegate methods for several views in
one controller object. That's why delegation /can be/ better than
subclassing. You don't need a subclass of each view (and for example
NSTextView *does* delegate some of its tasks) just to implement
application-specific logic. You can use the standard objects
unchanged and as-is.
So if I want to make event handling delegatable then I have to
override
the NSResponder methods and individually do the (short version):
if(respondsToSelector) doDelegateMethod
else doItHere
Or implement what I surmise the Framework does, which would be to
override forwardInvocation, create a dictionary listing sels for
delegatable
methods and default nils, some of which would be replaced by
delegate method
sels when setDelegate is called. I assume the dispatcher checks
here first
before calling any methods. Am I getting warm?
You're giving too little context for me to give a definite opinion,
but it doesn't sound wrong, at least. It really depends on what
you're trying to achieve. If you want to make it delegatable for
*all* NSResponder subclasses, you'll have to take a slightly
different approach (see method swizzling).
As to that last paragraph, I can't really follow you there. I
personally just do a respondsToSelector: and if that's true call the
method. Simple code is more easily maintainable, and I wait with
screwing up my code's readability by optimizing it until I've
profiled it, at which point Shark usually points me at much more
important sections of code.
Cheers,
-- M. Uli Kusterer
http://www.zathras.de
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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