Women in Technology

Hear us Roar



Article:
  Cocoa Vs. Carbon?
Subject:   Cocoa Vs. Carbon
Date:   2001-05-23 10:28:39
From:   ali1
Carbon and Cocoa have some interdependencies, but it is not the case one is built on the other; especially like MFC is built on Win32, or MacApp or Powerplant are built on the Mac Toolbox.


There are instances where Cocoa uses higher levels of Carbon --- the menu bar and the print dialog are the two examples. But this is really an implementation detail from an application developer point of view, who is using the respective APIs of each framework. The example provided above --- that the save dialog in Cocoa is Carbon --- is actually not correct; Cocoa has its own dialogs for save/open, font, color, spelling... But, again, an implementation detail.


The highest degree of sharing between Cocoa and Carbon is achieved by making the common services both need available at lower levels. That is why Carbon and Cocoa both appear as peers, in a layer above the ApplicationServices, CoreServices, and System boxes. These common services include APIs that are traditionally Carbon, traditionally Cocoa, and new --- examples are ATS, OpenGL, Quartz, CoreFoundation, LaunchServices... This approach allows high degree of code and data sharing, and interoperability. Where the two frameworks end up differing most is how they package and present these lower level APIs to the apps --- procedurally, or in an object-oriented fashion.



From a developer point of view, I think the best way to think of both is as described in the article --- Carbon for existing apps, and apps that need to run on Mac OS 9 and X both; Cocoa for new apps. How much they interdepend is an implementation detail, as each has their own, independent APIs, and as Scott Forstall said, Apple is committed to carrying both forward as the native frameworks of Mac OS X.


Ali

Full Threads Oldest First

Showing messages 1 through 3 of 3.

  • James Duncan Davidson photo Cocoa Vs. Carbon
    2001-05-23 12:00:41  James Duncan Davidson | O'Reilly AuthorO'Reilly Blogger [View]

    When looking at the actual codebases inside, you are right is that Cocoa doesn't build on top of Carbon the same way that Powerplant builds on top of the Mac Toolbox. But, from the point of view of a developer looking at the APIs, especially a new developer to the platform, I think that looking at them as peers creates the Carbon vs. Cocoa discussions that we see. Looking at them as building on each other is a reinforcement of the view that object-oriented technologies build on procedural ones.


    As you help to illustrate when talking about how both APIs utilize Quartz, CoreFoundation, etc -- it is actually simplistic to look at the APIs either as peers or building on each other, but for better or worse, we sometimes need such simplistic views even though no one simple view is an accurate reflection of the situation. And the primary myth that I am trying to debunk in the article is that either Cocoa or Carbon are the one true API for OS X.

    • Cocoa Vs. Carbon
      2001-05-23 13:51:13  halliday [View]

      You state: "the primary myth that I am trying to debunk in the article is that either Cocoa or Carbon are the one true API for OS X."

      A, potentially, laudable goal, but not, entirely, true---at least from an historic perspective (thus, it's subject to change as things evolve).

      When you look at the history of this system, you see that BSD (and Mach services) and Cocoa (nee Yellow-Box, nee OpenStep) were there first. Java came next, and Carbon is the late comer (only added at the behest of developers that baulked at the idea of having to completely rewrite their old apps [highly understandable, to be sure]).

      Unfortunately, the weight of legacy APIs is strong, so, now that the legacy Carbon APIs are here they are likely to be here for a long time (besides, Apple doesn't want to rehash the issues that lead to the inclusion of Carbon---only if, and when, Apple sees that few significant apps use Carbon will it go away). So now Apple is having to deal with this situation.

      The best they can do (without throwing out the heavy weight Carbon based developers, or the significant, potential, competitive advantage of Cocoa) is to make the two peacefully coexist, without draining their development resources with a long term parallel development program.

      Their strategy will, almost certainly, be based upon code reuse (probably via a combination of basing Cocoa atop Carbon, when that makes sense, and factoring lower level code bases from both Carbon and Cocoa), developer migration (hence the sails pitch about Carbon for legacy and Cocoa for the future [but they'll carry Carbon forward so as not to anger the legacy developers]), and cross language tools (most notably the Objective-C++ compiler that was available in the NeXT era, but dropped early on with Apple---they are repenting this decision).

      Unfortunately, basing Cocoa on procedural APIs (whether Carbon, or a factored, lower level procedural framework) will, probably, slow development and technological advances. However, with tools like the Objective-C++ compiler, perhaps this procedural overhead can be minimized. (That's my hope, anyway.)
      • James Duncan Davidson photo Cocoa Vs. Carbon
        2001-05-23 14:24:20  James Duncan Davidson | O'Reilly AuthorO'Reilly Blogger [View]

        I definitely agree with you that from the historical perspective that Cocoa is the "Native" API. And after experiencing it (and having been a long time developer on the Java platform), I think that I would have really liked a Mac OS X without Carbon. But now that Carbon and Cocoa have been mixed, shaken and stirred into OS X, the historical perspective does not serve us that well. Just like the historical perspective of Java having been originally developed for small machines like interactive TV boxes doesn't do service to the current reality of Java in the enterprise.

        With that in mind, I'm pretty happy to see the two sets of APIs co-exist, share functionality under the cover, and even build on each other. And after seeing Scott Forstall talk about how they go together, I have good hope that they will be able to develop both without undue harm to either.