• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Delegates -- WHAT is delegated?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Delegates -- WHAT is delegated?


  • Subject: Re: Delegates -- WHAT is delegated?
  • From: mmalc crawford <email@hidden>
  • Date: Wed, 20 Dec 2006 14:31:30 -0800

Please use the correct subject line for a thread -- if you reply to a message in the Digest, replace the Digest subject line with that of the thread to which you are replying.



On Dec 19, 2006, at 9:05 PM, Sam Colombo wrote:

Silly me, I was looking in the headers where I would expect to find it.

The official documentation for Apple's API is, unsurprisingly, in the documentation... available at
<http://developer.apple.com/documentation/>
or in Xcode.


That said, most delegate methods are listed in the class for which they are relevant (NSApplication.h, NSWindow.h, NSToolbar.h, etc. -- typically in an appropriately-named category...
@interface NSObject(NSApplicationDelegate)
@interface NSObject(NSWindowDelegate)
@interface NSObject (NSToolbarDelegate)
etc.).



On Dec 20, 2006, at 1:14 PM, Sam Colombo wrote:

So the bottom line is that there is no sure way to identify what is
delegatable from the supplied headers themselves. You have to depend on the
occasional comments, protocols with "delegate" in their title, and
Notifications (or just look in the documentation)


All public delegate methods are listed in the documentation. It's not clear why "look[ing] in the documentation" appears to be a problem?



I can see why subclasses are good for the specialized views mentioned,
but where I am really going is the main view where I intend to have a s--t
load of layers and content types that each need their own handlers (i.e.,
controllers). I like the MVC concept, but I would like to keep the C out of
the V.


If you're implementing your own class, you're free to do so how you wish. If you want to provide a specific controller for a view -- that is perhaps required to implement a given set of methods (ideally specified by a formal protocol) -- they you're perfectly able to do just that. Consider NSTableView as an example that uses both a delegate and a data source (these are frequently the same object, but need not be).

mmalc

_______________________________________________

Cocoa-dev mailing list (email@hidden)

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:
This email sent to email@hidden


References: 
 >Re: Cocoa-dev Digest, Vol 3, Issue 1474 (From: Sam Colombo <email@hidden>)

  • Prev by Date: NSKeyedUnarchiver incomprehensible archive exception
  • Next by Date: Re: Delegates -- WHAT is delegated?
  • Previous by thread: Re: Cocoa-dev Digest, Vol 3, Issue 1474
  • Next by thread: Re: Delegates -- WHAT is delegated?
  • Index(es):
    • Date
    • Thread