The bottom line is that until cocoa implements a wrapper for EVERY carbon feature, or finishes implimenting their incomplete wrappers (look at NSAppleScript compared with Apple Eevents and see how much fuctionality is left out), cocoa and carbon will just have to go hand in hand.
Carbon still has a myriad of crucial features that cocoa doesnt. I still use carbon events to create hotkeys and CGSEnableGlobalHotkeys to allow my hotkeys to be called anonymously.
I think when it comes down to it, alot of cocoa developers, at least in my experience, are very poor STL programmers. Most cocoa developers I have met seem to use just the "carbon is old and horrible" saying just to mask the fact that they don't know how to properly malloc structs, use hash tables, or research through the poor documentation to find out which type certain functions take.
I'll be the first to admit that carbon does take far more effort, and I am a cocoa programmer, but I still use carbon on a regular basis to impliment features which otherwise could not be done in cocoa.
Sorry if this sounds grammatically incorrect, i wrote this in a hurry.
by Matt Tavares — Oct 07
Carbon still has a myriad of crucial features that cocoa doesnt. I still use carbon events to create hotkeys and CGSEnableGlobalHotkeys to allow my hotkeys to be called anonymously.
I think when it comes down to it, alot of cocoa developers, at least in my experience, are very poor STL programmers. Most cocoa developers I have met seem to use just the "carbon is old and horrible" saying just to mask the fact that they don't know how to properly malloc structs, use hash tables, or research through the poor documentation to find out which type certain functions take.
I'll be the first to admit that carbon does take far more effort, and I am a cocoa programmer, but I still use carbon on a regular basis to impliment features which otherwise could not be done in cocoa.
Sorry if this sounds grammatically incorrect, i wrote this in a hurry.