On 19 May 2008, at 17:22, john darnell wrote:
As far as I can tell, it is kind of like a virtual function (virtual
because I, the programmer, am expected to flesh it out) that resembles
an event attached to a given class.
You're in the right ball park.
The bit you're missing is that with virtual functions the overloading
is done in a subclass at compile time, and with delegates it's done
with any class at runtime.
Say we had two classes (ClassA & ClassB). ClassB DOES NOT have to be
any relation to ClassA (Super, Sub-Class, or anything else). An
instance of class B can tell an instance of class A's that it wants to
be it's delegate. After that, when ClassA is doing something it can
check to see if it has a delegate, and if so call it.
~~~~~~ Somewhere in ClassA ~~~~~~~~~~
ableToKickIt = NO;
if ([self delgate])
ableToKickIt = [delegate canWeKickIt];
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(It's not quite written like that, but it gets the point across)
Points to note:
* We're talking about instances, not classes, so you have a delgate
object for A window, or A document, not all windows, or all documents.
* Behaviour might change as the as the application runs, so a
different instance of ClassB might be set as the delegate later on.
Alternatively it could be a completely different class, ClassC.
* Sometime you see code where an object set's itself to as it's own
delegate. This is normally done because for other reasons the author
has decided to write a subclass, and rather than have the delegate
methods elsewhere it makes sense to have them in the same place. It
doesn't have to be done this way though.
It has specific times when it is
called and at that time it may perform just about any duty that the
programmer can dream of, or she can stick to something that relates to
the object calling it.
Yes, although it's normally best to keep with the second option.
In almost every description of a delegate that I
perused, I found the words "when" or "before," which is why I
related a
delegate to an event.
"should" returns a yes/no to say should the action occur. e.g.
applicationShouldTerminate
"will" is notification of an event before it happens e.g.
applicationWillTerminate
"did" is notification of an event after it happens e.g.
applicationDidFinishLaunching
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please 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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
