Re: Cocoa's custom class delegate conventions
Re: Cocoa's custom class delegate conventions
- Subject: Re: Cocoa's custom class delegate conventions
- From: Greg Titus <email@hidden>
- Date: Sat, 14 Jun 2003 15:41:29 -0700
On Saturday, June 14, 2003, at 12:20 PM, Sherm Pendley wrote:
On Saturday, June 14, 2003, at 04:24 AM, Sailor Quasar wrote:
For that matter, once you've confirm that [delegate
respondsToSelector:@selector(thingWillDoStuff:)], why in the world
can't you simply then call [delegate thingWillDoStuff:self] directly?
It's an id after all, and I believe one of the rules of ids is that
you can send any selector to them that they recognize.
You can, and at run-time it will work swimmingly. At compile-time,
however, you'll get lots of compiler warnings about it.
No, if you follow the standard pattern of declaring your delegate
methods as a category, you will not. (See any of the AppKit class
headers which have delegates for examples.) If an object is declared
"id", then you will get no compiler warnings when sending any message
to that object, as long as the selector exists at all. (Declaring the
selector in a category interface informs the compiler that the selector
exists, even if the compiler sees no implementation.)
@interface NSObject (MyViewDelegate)
- (void)thingWillDoStuff:aThing;
@end
Hope this helps,
- Greg
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.