Re: Category or Protocol? (objc newbie)
Re: Category or Protocol? (objc newbie)
- Subject: Re: Category or Protocol? (objc newbie)
- From: Ondra Cada <email@hidden>
- Date: Tue, 19 Apr 2005 18:52:40 +0200
Rick,
On 19.4.2005, at 17:33, Rick Kitts wrote:
Ah. This is pretty sexy.
Welcome in Objective C :)
So categories are 0 runtime cost constructs?
Yup.
More precisely, there is some *completely negligible* load-time penalty
for category implementations, for that's the time they are added to
classes. Declared-only categories (aka informal protocols) though have
no runtime consequences at all--they serve in ObjC kind of the same
thing as function prototypes in plain C: they just inform the compiler
of available messages and their argument and return types.
Your example also seems to raise the question of how should one deal
with the delegate. It seems that I could either create a default/do
nothing implementation or I could send a respondsTo: message to the
delegate. I'd presume that the former is faster at runtime, whereas
the second seems to better convey what's actually happening
Quite, which is why the latter is the way how to implement delegates.
Another good reason is that the delegate can be just any object,
without any presumptions of its class (or protocol conformance). Heck,
in special cases it might be even a class (not an instance), perhaps
even a library class with the appropriate delegate methods added using
a category :))
Note also the delegate communication normally should not be a
bottleneck, and thus the slight efficiency price should not be
important. If it is so though in a special case, you can exploit the
IMP-caching technique to make it *far* more efficient for a price of
some slight flexibility loss.
(note: For what I'm doing there *is* a reasonable default behavior and
this is what raises this issue for me).
That may indicate what you actually want to is *not* a delegation.
The delegation pattern, on the other hand, means that if there is a
sensible default behaviour, it is to be done not delegate-side, but the
other side -- if there is no delegate || if the delegate does not
respond. Conceptually, it means something like
if ([delegate respondsToSelector:@selector(delegateMessage)]) [delegate
delegateMessage];
else {
// default behaviour here
}
or perhaps even if the delegate allows
// presumed the delegate method returns a BOOL, whose YES means to use
the default (to be documented of course)
if (![delegate respondsToSelector:@selector(delegateMessage)] ||
[delegate delegateMessage]) {
// default behaviour here
}
Any suggestions?
Depends on the task. It is quite all right to make the co-operating
object to be a subclass of a specific class, or at the least to conform
to a specific formal protocol(*), but in these cases it should not be
called "delegation" not to confuse other programmers :)
(*) in which case though it is not that easy to provide a default
behaviour without re-direction :)
BTW I think what I'm looking for, ideally, is a sort of best practices
forum or something. Objc is trivial to learn but, like most languages,
difficult to skillfully wield.
This is the forum, in my personal opinion :)
An Effective Objective-C book would be really useful.
Got a publisher? I'd be glad to write one :))
---
Ondra Čada
OCSoftware: email@hidden http://www.ocs.cz
private email@hidden http://www.ocs.cz/oc
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden