Cocoa mail archive
Re: How viable is Cocoa development?
FROM : Rainer Brockerhoff
DATE : Sat Jan 26 15:32:40 2002
At 14:35 +0100 26/01/2002, Ondra Cada wrote:
> >>>>>> Rainer Brockerhoff (RB) wrote at Sat, 26 Jan 2002 02:30:35 -0200:
>RB> ... Quite a few parts of Cocoa seem to be
>RB> just a thin shell over the equivalent Carbon calls.
>RB>
>RB> You might argue that this is a consequence of HFS+ support, I suppose...
>
>I would argue it is a consequence of a bad design. I would argue it should
>have been done the very opposite way:
>
>(i) extend Cocoa to cope properly with HFS+ and other news, and...
>(ii) make Carbon a thin compatibility shell over it!
>
>That way the application consistency would be *WAYS* better, there would be
>no problem of APIs lacking in Cocoa, and what seems to me to be the MOST
>important, the applications would be also runtime-consistent: things like
>Mike Ferris' TextExtras or my OCSmart Hacks would properly work system-wide
>(but Classic of course, but Classic is explicitly an emulator).
Well, that's of course a basic design decision made when the order of the layers was decided upon, and no amount of lamenting will change that now. :-)
I agree with you that implementing Carbon on top of Cocoa (instead of the other way around) would have had advantages such as those you list. However, one could also argue that this would have made Carbonized apps even slower than they are now, with all that dynamic-dispatching stuff going on underneath, and no way to get around it...
That said, I certainly like Cocoa a lot, and I won't write a Classic or Carbon app (meaning, built around the Carbon event model) ever again. However I still prefer to call non-Cocoa APIs whenever I need to get closer to the metal.
--
Rainer Brockerhoff <<email_removed>>
Belo Horizonte, Brazil
"I love deadlines. I love the whooshing noise they make as they go by" (Douglas Adams)
http://www.brockerhoff.net/ (updated Jan. 2002)
DATE : Sat Jan 26 15:32:40 2002
At 14:35 +0100 26/01/2002, Ondra Cada wrote:
> >>>>>> Rainer Brockerhoff (RB) wrote at Sat, 26 Jan 2002 02:30:35 -0200:
>RB> ... Quite a few parts of Cocoa seem to be
>RB> just a thin shell over the equivalent Carbon calls.
>RB>
>RB> You might argue that this is a consequence of HFS+ support, I suppose...
>
>I would argue it is a consequence of a bad design. I would argue it should
>have been done the very opposite way:
>
>(i) extend Cocoa to cope properly with HFS+ and other news, and...
>(ii) make Carbon a thin compatibility shell over it!
>
>That way the application consistency would be *WAYS* better, there would be
>no problem of APIs lacking in Cocoa, and what seems to me to be the MOST
>important, the applications would be also runtime-consistent: things like
>Mike Ferris' TextExtras or my OCSmart Hacks would properly work system-wide
>(but Classic of course, but Classic is explicitly an emulator).
Well, that's of course a basic design decision made when the order of the layers was decided upon, and no amount of lamenting will change that now. :-)
I agree with you that implementing Carbon on top of Cocoa (instead of the other way around) would have had advantages such as those you list. However, one could also argue that this would have made Carbonized apps even slower than they are now, with all that dynamic-dispatching stuff going on underneath, and no way to get around it...
That said, I certainly like Cocoa a lot, and I won't write a Classic or Carbon app (meaning, built around the Carbon event model) ever again. However I still prefer to call non-Cocoa APIs whenever I need to get closer to the metal.
--
Rainer Brockerhoff <<email_removed>>
Belo Horizonte, Brazil
"I love deadlines. I love the whooshing noise they make as they go by" (Douglas Adams)
http://www.brockerhoff.net/ (updated Jan. 2002)
