Linked by Thom Holwerda on Sun 24th Jun 2007 21:58 UTC, submitted by Jeremy Fox
Thread beginning with comment 250421
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
One thing to realize, is that only the UI portion of Carbon is being deprecated for 64bits.
Which means, a Carbon app needs only its UI to be redone in Cocoa, to be available as a 64-bit app. Apple is saying that Cocoa and Objective-C is the future for native UIs on Mac OS X. What's underneath is entirely up to the developer.
Which means, a Carbon app needs only its UI to be redone in Cocoa, to be available as a 64-bit app. Apple is saying that Cocoa and Objective-C is the future for native UIs on Mac OS X. What's underneath is entirely up to the developer.
Why should Apple decide what framework an application is being developed for? If Cocoa has any advantages (speed, maintainability etc.) to Carbon the developer would be wise to choose it.
Otherwise it doesn't have much of an added value. If I preferred Carbon then it wouldn't matter to me if it's 32-bit, 64-bit or 128-bit.
Can you give me a reason why Cocoa and Obj-C should be considered the future and what makes them so much better than Carbon and C/C++?
@psychicist
Can you give me a reason why Cocoa and Obj-C should be considered the future and what makes them so much better than Carbon and C/C++?
Because of the bloody OOP hype. Carbon is not OOP, the same way Win32 is not OOP. Microsoft's idea of OOP is the atroscity we know as MFC and COM. .Net is MS' attempt to make things right. Cocoa is an OOP API that's been around for some time. This is just simply how things fell into place.





Member since:
2006-01-05
One thing to realize, is that only the UI portion of Carbon is being deprecated for 64bits.
Which means, a Carbon app needs only its UI to be redone in Cocoa, to be available as a 64-bit app. Apple is saying that Cocoa and Objective-C is the future for native UIs on Mac OS X. What's underneath is entirely up to the developer.
Most code is cross-platform on the backend anyway, and the low level API calls can still be in Carbon, Cocoa, or just plain CoreFoundation.
Also, the UI part of the code is already non-cross platform if you do it in pure Carbon (just like in Cocoa). And if you use libraries like wxWidgets or equivalent, those libraries simply need to interface to Cocoa, and all is set (though, most likely a lot of these would need recoding, since I think they use Carbon at this time).
Edited 2007-06-25 14:23