Mailing Lists: Apple Mailing Lists

Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Cocoa Pros & Cons (was err, Mac OS X)



Metrowerks PowerPlant/Constructor? I would be very interested to hear from
any experienced PowerPlant user who has tried Cocoa and found it to be
amazingly superior (I rather doubt anyone has).

I've used PowerPlant since the early days and wrote the original version of Constructor. I also have considerable experience in MacApp all the way back to Object Pascal. In general I'm fairly agnostic about languages and frameworks (aside from the fact that I need one or more of each). IMO, there are some things about Cocoa that are amazingly superior and some things that are less desirable.

It took me about a week to get comfortable enough with Objective-C that I wasn't constantly looking up the syntax of something. It takes quite a bit longer to be fluent enough that you start to design with the unique features such as categories. There are things that Objective-C could teach C++ and/or Java and vice-versa.

PowerPlant (like MFC) is a fairly "shallow" framework. It doesn't take long until you're down into the underlaying API. MacApp is deeper in that you tend not to call the toolbox very often. Cocoa is a very deep but you still call into the underlaying API (e.g., Unix or the graphics subsystems) from time to time. It's nice that things like memory management and naming conventions are more consistent throughout.

The priorities in Cocoa have been different than typical Macintosh frameworks. For example, the text editing class is very full featured but in the Rhapsody timeframe the Yellow Box (aka Cocoa) didn't have a standard document class or undo mechanism. These have been added over time but sometimes the Cocoa solution is rather different than what is typical, although not necessarily better or worse.

The memory management strategy in Cocoa is very powerful but can take a little time become fluent with so that you stop making stupid mistakes. In fact I like it well enough that I've recreated it in C++ for other projects. Objective-C has some nice features for doing RPC's transparently. Interface Builder is more tightly coupled to Cocoa than Constructor is to PowerPlant.

I'm used to having the source code to my framework available so the lack of it in Cocoa can be annoying. If I'm not getting what I expect I can't look at what the framework is doing or step through it in the debugger. Of course with CarbonEvents a similar situation is starting to exist in Carbon. The lack of the Cocoa source code can make it very difficult to do something orthogonal to what the designers had in mind.

In the end, the benefit of using Cocoa or any framework is related to how much of the framework code you can reuse as a percentage of the overall size of your project. If you intend to create a Mac OS X only version of SimpleText by all means use the text class in Cocoa and slap it together in five minutes. On the other end of the spectrum, if you have a huge multiplatform project that requires dozen of man-years, you might be better off writing your own framework with C++ throughout.

Regards,
Nick Nallick
_______________________________________________
carbon-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/carbon-development
Do not post admin requests to the list. They will be ignored.

References: 
 >Re: NeXTstep -- err, Mac OS X. (From: Larry Gerndt <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.