On 11/06/2009, at 11:25 PM, Jo Meder wrote:
It's not really so simple, because I'd have to subclass all the views/controls I use, which is many of the UI elements available, and that means I have many disparate classes implementing the same functionality. Of course I then need to repeat that for any new controls I support. Less work and maintenance to maintain a map from NSViews to my C++ framework objects. I should have mentioned I had considered and rejected subclassing I guess.
Yes, this situation can be painful, as we don't have multiple inheritance. I ran into the same problem last week where I wanted to add a data member to an ancestor class for a whole family of objects.
Adding methods of course is easy using categories, but adding storage to a common ancestor class isn't. In this case you might have to resort to tables.
Thanks anyway. I was a long time MacZoop user BTW. Well, some of MacZoop, I used all my own control classes. I use a messaging and commander system inspired by my experience with MacZoop in my own framework.
Yes, I remember your name. I would say that Cocoa's messaging and commander classes are generally better thought out than MacZoop's, which was somewhat based on my earlier experiences with TCL - anyone remember that? ;-)
--Graham _______________________________________________ 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
