Re: OBJ-C question
Re: OBJ-C question
- Subject: Re: OBJ-C question
- From: Shaun Wexler <email@hidden>
- Date: Sat, 17 Apr 2004 11:04:30 -0700
On Apr 17, 2004, at 10:37 AM, Sherm Pendley wrote:
I'm confused - your advice is seemingly contradictory to Apple's
practice. Looking at AppKit headers such as NSWindow.h,
NSOutlineView.h, and NSBrowserView.h, I see all of the delegate and/or
data source methods that are relevant to each class added to NSObject
as a category.
This pattern, to me, seems worth following - the default method that's
added to NSObject does nothing, and users who provide a delegate
and/or data source class can override this behavior as they wish. And
even if they don't, no warnings about unrecognized methods are
produced.
The @interface is added to NSObject as a category, but it's just a
"header category", with no actual implementation of the methods.
Before calling delegate/datasource methods, an object must check to see
if that message is implemented somewhere in the class heirarchy before
messaging the object, using -respondsToSelector:@selector(doSomething).
It would work either way, but if you had not declared the interface
category, the compiler would warn that the object may not implement the
method, in which case you'd have to pass the message using
-performSelector:@selector(doSomething) instead of conveniently using
-[delegate doSomething].
There's also efficiency to consider - without a default
implementation, you have to call respondsToSelector: before each call
to a data source method. You couldn't simply call it in setDataSource:
because the method could be added to the class after the data source
object has been assigned. Not only would this clutter up your code, it
would introduce a bottleneck in what is usually a frequently-called
time-critical method.
I am about to write a much-needed ObjC low-level function to combine
the two and provide the method -performIfRespondsToSelector: which I
feel would be a valuable addition to NSObject. This function will
cache the method lookups the same way as objc_msgSend, for
efficiency...
What am I missing? The only drawback I can think of is polluting
NSObject with a bunch of do-nothing default methods, but with
carefully-named methods that's hardly a critical problem.
As long as you don't write empty method implementations on NSObject, it
doesn't pollute anything to use it for your interface category
declarations. If you were to declare a formal Protocol, that in fact
is an (ancient) object itself. ;)
--
Shaun Wexler
MacFOH
http://www.macfoh.com
_______________________________________________
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.