1) Why is it, when you create a new Cocoa Application (or even some
iOS Applications) in Xcode, does it generate <blahblah>AppDelegate
(.h and .m) files, instead of calling them <blahblah>Controller (.h
and .m)? Since these tie to the <blahblah>.xib - according to MVC
paradigm - shouldn't it be a controller object for the view(s) in the
xib (a controller that just so happens to be a delegate)? After all,
it's not called the MVD (Model-View-Delegate) paradigm! Yeah, I
realize this is just a stylistic thing, but hey, it gives me an
excuse to ask this question! Likewise, when you open the xib in IB,
you see a proxy object called <blahblah> App Delegate. Again,
shouldn't this be <blahblah> Controller to maintain the 'feeling'
that you're designing according to the MVC paradigm?
2) How come some NSControls have both a delegate API and a data
source API? I'm thinking mostly of NSTableView and its ilk, such as
UITabView. Why not just have one delegate API that has the data
source 'messages' in that implemented protocol?
_______________________________________________
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 arch...@mail-archive.com
