Re: Implementing delegate categories for subclasses

Ouch, that code looks like pain. Pain to define in your header file,  
pain to implement simple interaction with delegates and difficult to  
read for third parties.

I don't know what the "right way" to do things is but I'm willing to  
throw my opinion in the fire to better my own code practices and the  
practices of others. My two cents are inspired by the example of the  
NSTableView delegate. For all the optional methods in the protocol,  
NSTableView would have to test if the delegate responds to the  
optional method and then invoke it. Ugh. With a category of NSObject,  
NSTableView can happily call this optionally overridden delegate  
method and the default implementation can simply be a no-op.

Personally, I define my delegate methods as categories of NSObject,  
throwing exceptions when the required methods are not implement (a la  
NSTableDataSource). If the most trivial testing doesn't expose the  
exceptions then the implementation doesn't deserve to be required. I  
figured the repetition of typing [foo respondsToSelector:@selector 
(bar:)] was tiresome and unnecessary as I explained in the example  
above.

Goodnight all,

Kiel
"Home is not where you are born, but where your heart finds peace."
Tommy Nordgren

On 09/09/2009, at 10:39 PM, Christiaan Hofman wrote:

> As you all know SL has replaced all informal delegate protocols by  
> formal protocols. This gives me some problems when subclassing  
> classes that should extend such a protocol. In particular if I want  
> to be able to use the same code for both the 10.6 and 10.5 SDK.
>
> The docs recommend implementing empty protocols for the new NS ones  
> conditional on using an old SDK (MAC_OS_X_VERSION_MAX_ALLOWED).  
> However, I have yet not been able to find any recommendations how  
> best to handle subclasses, in particular in this situation.
>
> So would someone on this list have an idea what the best way is to  
> handle this situation?
>
> A big problem is the fact that @optional is not supported with the  
> 10.5 SDK. The only way I can think of is to add it conditionally on  
> the SDK, and use an informal protocol for 10.5.
>
> Here are some things I tried. Take as an example an NSTableView  
> subclass.
>
>
> @protocol MYTableViewDelegate <NSTableViewDelegate>
> #if MAC_OS_X_VERSION_MAX_ALLOWED  <= MAC_OS_X_VERSION_10_5
> @end
> @interface NSObject (MYTableViewDelegate)
> #else
> @optional
> // extra delegate methods here
> @end
>
> @interface MYTableView : NSTableView {
> 	// extra ivars here
> }
> // extra method declarations here
> - (id<MYTableViewDelegate>)delegate;
> - (void)setDelegate:(id<MYTableViewDelegate>)newDelegate;
> @end
>
> @implementation MYTableView
> // extra method implementations here
> - (id<MYTableViewDelegate>)delegate {
> 	return (id<MYTableViewDelegate>)[super delegate];
> }
> - (void)setDelegate:(id<MYTableViewDelegate>)newDelegate {
> 	[super setDelegate:newDelegate];
> }
> @end
>
>
> However, this gives warnings when using the 10.5 SDK when I try to  
> use the delegate with my new delegate methods, because the  
> MYTableViewDelegate protocol is empty. However, when I don't  
> override the -delegate and -setDelegate methods, I get warnings when  
> using the 10.6 SDK, because the delegate is only conforming to  
> NSTableViewDelegate.
>
> So my question is whether I'm doing things right this way, how to do  
> it better, and what would be the recommended way to handle this?  
> Perhaps we can get some discussion going here that would make some  
> recommendations going into the docs.
>
> thanks,
> Christiaan
>
>
> _______________________________________________
> MacOSX-dev mailing list
> [email protected]
> http://www.omnigroup.com/mailman/listinfo/macosx-dev