Quote:
Originally Posted by
VanFruniken 
It has been clear from the beginning that Carbon wouldn't be around for ever.
Further, the fact that images continue to grow and are expected to exceed 4GB, is unavoidable. Didn't Adobe see this problem coming?
They could have saved a lot of time because development under Cocoa is
- much faster (because the system takes care of a lot of things behind the scenes that under Carbon need to be hard coded)
Name one 'thing' of this nature.
Carbon apps are often faster than Cocoa apps. In fact, this is usually the case.
I use both APIs, and while Cocoa is usually quicker to develop the claim that Cocoa apps are "much faster" is absurd. It's like expecting Gnome apps to run faster than GTK ones.
Quote:
- much more robust
As already pointed out in previous posts, they would have gotten the transition from PPC to Intel almost without effort, had they switched to Cocoa
This is not an issue with programs which are already multiplatform, and isn't much of an issue with most other Carbon apps.
The sad fact is Apple yanked 64bit Carbon just before it hit beta for political reasons. It has nothing to do with feasibility or practicality and everything to do with what stick is up Lord Steve's ass at the moment.
Another sad fact is that Cocoa can't replace Carbon for all things, and for a variety of reasons:
Cocoa is a higher level API than Carbon written in a different language. It would make as much sense to replace Carbon with Swing. This affects not only Photoshop, but all non-Cocoa APIs, which are many because Cocoa is not an all-encompassing framework. Carbon had deficits here, too, which is why Apple's 'Core' APIs were made and are being extended. Cocoa is better thought of as a good replacement for PowerPlant or MacApp. ObjC is better than C++, hallelujah, but why remove the C hooks altogether?
Cocoa was written in the UNIX methodology which has human interface repercussions. There is no Cocoa FSRef equivalent, there is no Cocoa alias equivalent, and there is no Cocoa equivalent for a lot of low-level event handling. There are perfectly good reasons why Cocoa still uses Cocoa events, Menu manager, etc. (which, magically, have no issues running as 64bit). Apple still has yet to get to grips with missing APIs and the general schizophrenic nature of OS X. Apple has quite the GALL to demand developers use incomplete APIs.
The world is changing, and the new paradigm is platform independence. Instead of leading the way by making Cocoa available everywhere, Apple decided to keep it to themselves meanwhile expunging Carbon which only makes OS X a less relevant platform. The bridge to .NET still sucks and Apple obviously doesn't consider such things relevant while it keeps making itoys for Steve to play with his gay friends. If Apple (or rather Steve) continues on its imperial path of trying to force ObjC down the throats of the barbarians, they will find themselves without even a remnant to remember what Mac OS X ever was.
There is absolutely NO damned reason to drop Carbon! We have excellent code which uses Carbon every day, and in many cases follows Apple's HI guidelines BETTER than Cocoa equivalents. The lack of a complete Cocoa Mac API has caused a lot of cross-fertilization and dependence on Carbon, but that's better than the alternative of only having Cocoa apps.
What it boils down to is mindless zealotry by fools who have never written Carbon apps.
