Article:		Cocoa Vs. Carbon?
Subject:		RE: I thought carbon would be the interim API ..
Date:		2001-05-23 12:16:38
From:		duncan
Response to: I thought carbon would be the interim API ..
I thought that as well for a while as a Java developer working primarily with UNIX and Windows while diving into the early Mac OS X DP releases. Bits and pieces of that thinking have been challenged for me as I've dug deeper and deeper into OS X and the APIs and how they go together. For example, why would the Finder be Carbon if Carbon was just an interim API? It was Monday's Frameworks talks at WWDC that really turned the lightbulb on as to how they go together. As far as taking advantage of all of OS X fundamental strengths, such as MP and preemptive threading, Carbon can use the system as well as Cocoa. Where Cocoa really shines is in all of the functionality that you get for free (such as spell checking), the ability to interface with other applications via Services, and a whole host of other really neat things enabled by the object-oriented nature of the framework.

Showing messages 1 through 1 of 1.

• RE: I thought carbon would be the interim API ..
  2001-05-23 13:12:21  halliday [Reply | View]
  
  
  As to your question of "For example, why would the Finder be Carbon if Carbon was just an interim API?" The answer has already been given by Apple: To show developers that significant applications can actually be done in Carbon. So the Carbon Finder was "proof of concept" and has nothing to do with whether writing the Finder in Carbon is a good idea. (It also helped Apple work out some of the bugs and deficiencies in Carbon.)
  
  However, we can certainly see that Apple cannot continue a course where Cocoa and Carbon are on parallel development with all their own implementations. This is simply impractical, especially in the long term.
  
  This means that either Apple has to find some way to jettison one of these approaches (a highly undesirable prospect for Apple, I would say [though, personally, I would love to see Carbon go the way of the dinosaurs]), or they have to find some way to utilize the implementation in one framework from another (reuse).
  
  Unfortunately (for Apple, and for Cocoa developers), it is generally far easier to base an object oriented framework upon a sufficiently low level procedural one than it is to do the reverse (though you can wrap a very high level procedural framework upon a well factored object oriented one). This suggests that as things progress, we can expect to see either Cocoa based upon Carbon, or both based upon still lower level procedural frameworks (as is the case for much of the drawing and event handling).