Re: Re: Re: G4i? Or... "Now for something completely different"?!?
It depends on which parts of Carbon/Cocoa that you actually mean. The interface toolboxes in Carbon & Cocoa are not thin at all, as they both implement the all of the functionality. The event system is based on lower level functionality. All windows are based on a common window API, but each toolkit adds additional functionality over this API. And the lowerlevel Carbon functions (like the File Manager) are based directly on BSD APIs. Cocoa also uses these Carbon functions as well as the BSD layer directly.
What I meant by saying that Cocoa would be foisted over Carbon is just the interface toolbox and the event system. That is all they would need to allow Carbon & Cocoa windows & widgets to coexist in the same application.
As for Carbon, it is not stagnating, but in fact growing to gain much of Cocoa's functionality, as evidenced by a number of Carbon oriented sessions at WWDC.
Originally posted by jettredmont
My understanding was that both Carbon and Cocoa are fairly "thin" (Cocoa being a bit thicker than Carbon) wrappers over the Core OS X code. In other words, these are not two separate implementations, just two separate interfaces into a common implementation. Which implementation is in C (going with the BSD subsystem).
IIRC, "Cocoa" and "Carbon" are APIs, not implementations.
If this is correct, then one can imagine the functionality of both APIs perhaps being made to have more in common (although I sense that the Carbon APIs are stagnating), but one API isn't really built "on" the other, nor would such a re-architecting make sense.
It depends on which parts of Carbon/Cocoa that you actually mean. The interface toolboxes in Carbon & Cocoa are not thin at all, as they both implement the all of the functionality. The event system is based on lower level functionality. All windows are based on a common window API, but each toolkit adds additional functionality over this API. And the lowerlevel Carbon functions (like the File Manager) are based directly on BSD APIs. Cocoa also uses these Carbon functions as well as the BSD layer directly.
What I meant by saying that Cocoa would be foisted over Carbon is just the interface toolbox and the event system. That is all they would need to allow Carbon & Cocoa windows & widgets to coexist in the same application.
As for Carbon, it is not stagnating, but in fact growing to gain much of Cocoa's functionality, as evidenced by a number of Carbon oriented sessions at WWDC.