|
I agree. Cross platform folks build their own Application frameworks, usually.
Also, game programmers, often don't want all the application layer stuff. Folks developing new languages (or new implementations, or porting implementations) don't necessarily want to buy into ObjC. All this is good stuff, and Apple should welcome these folks to X.
Since ObjC, which views objects as pretty coarse-grained, takes zero performance penalty for being built on top of a procedural layer, it seems like a good idea for Apple to keep a procedural layer around.
(The fact that C++ supports fine grained objects well, but is weak on the course grained stuff (not dynamic enough) is what made ObjC++ such a good thing.)
I think Carbon Events, which Cocoa seems to be built on top of, will survive, and some other key features, but a large portion of Carbon will slowly fade out as OS 9 disappears. It will be replaced with the Unix filesystem APIs, Mach memory management and thread packages, and the new procedural APIs, such as CoreGraphics and CoreAudio.
Dan
|
Apple *have* used Carbon to implement some of the Mac OS X Cocoa methods, but it isn't used from the ground up as your comment implies. They have also (helpfully) made it so that you can mix Cocoa and Carbon code in the same application. But that doesn't mean Cocoa is built on Carbon... it isn't; sure, some things use Carbon (NSMenu is a good example), but not everything does (which is why Cocoa apps behave subtly differently in many cases).