Well, you seem to be happy so far be it from me to spoil your mood...
But this makes very little sense to me.
What "delegate chain"? Do you mean responder chain? The responder
chain (if that *is* what you're referring to) is not an example of the
delegate pattern, it's an example of the "chain of responsibility"
pattern - different thing.
Delegation is usually a contract between two objects (at a time).
In your case, the sheet controller is only vaguely a delegate of the
FC - in most programmer's eyes I'm not sure that the term 'delegate'
would be applied here - it's just another object that the first object
(the FC) calls to trigger some process. Since this is happening all
the time in thousands of situations, most people don't describe that
as a use of the formal delegation pattern. While it might help you to
think of it that way, be careful about using terminology in a way that
isn't generally understood to mean that - it will confuse you and
others because 'delegate' has a specific meaning and you are misusing
it.
There is exactly one situation that your FC is a delegate - it's the
delegate of the sheet controller (SC) at the point where the sheet
controller has decided that the operation needs to be executed, and it
calls its delegate to perform it. It does this because it's only
concerned with managing the specific user interface it's dealing with
- it doesn't know what the UI "means" or what action is carried out
when the user hits OK - but the delegate does know what the real
meaning is, so the SC defers to it to carry out the appropriate action.
Very importantly, the FC might have triggered the process (displaying
the UI via the SC) but it is not required to complete it. A different
object could be responsible for that. In your case, it JUST SO HAPPENS
that the FC is the SC's delegate as well as the original instigator,
so it is playing a dual role (not unreasonably). But if a different
object were passed as the SC's delegate, that would be entirely
reasonable too. In which case your whole argument about why we call
the FC the 'delegate' is bogus - it has nothing to do with windows or
who started the process or who did what to whom - it's a simple 1:1
contract between two objects - the SC and its delegate, whoever that
may be. And *THAT'S* why the FC is called the delegate *from the
perspective of the SC*, and for no other reason.
Hope that helps,
Graham
On 18 Jul 2008, at 3:05 am, John Love wrote:
Now ... to delegate stuff ... I've reached a conclusion based on
ADC's "Cocoa and Objective-C" and on good-ole MW (haven't gotten
"Design Patterns" yet) that:
(1) the sheet is the delegate of FC because the FC is asking the
sheet what to do and the FC implements the sheet's decision
(2) (here is when the lights went on) the FC is the delegate of the
NSWindow because the window is asking the FC what to do and the
window implements the FC's returned decision. OF COURSE the FC is
the delegate of the NSWindow because that is the way IB has this
relationship hooked up.
(3) because the delegate "chain" is a chain, I have to go back up
the chain and ask "Who is the original delegate?" .. and the answer,
my friends, is the FC which is the delegate of NSWindow.
the window asks the FC, which then asks the sheet .. the
original delegate = FC, so that's what we always call the FC.
_______________________________________________
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]
