Re: [LONG] Making the right choice (was Re: How viable is Cocoa development?)
Re: [LONG] Making the right choice (was Re: How viable is Cocoa development?)
- Subject: Re: [LONG] Making the right choice (was Re: How viable is Cocoa development?)
- From: "Clark S. Cox III" <email@hidden>
- Date: Sun, 27 Jan 2002 19:13:23 -0500
On Sunday, January 27, 2002, at 04:52 , David Niemeijer wrote:
At 9:03 +0100 27/1/02, Marcel Weiher wrote:
On Sunday, January 27, 2002, at 03:03 , Erik M. Buck wrote:
1) If I want to take full advantage of OSX, and have fastest access to
the latest and greatest capabilities of the operating system as it
evolves, should I use Cocoa or Carbon??
Carbon.
Wrong: Carbon is easily usable from Cocoa, the other way around is much
more difficult (plus: if you do the main job in Cocoa, you will
actually have TIME to do the little bits of Carbon)
Ok, so how is Carbon easily accessible from Cocoa?
1) Can I call Carbon from an Obj-C, Obj-C++, C, or C++ file that is part
of a Cocoa application? If so, what special steps need to be taken?
Yes, no special steps are needed.
2) Can I, from a cocoa application, easily access a plug-in or shared
library containing Carbon based code? If so, what special steps need to
be taken?
I've never tried.
3) Can I easily share Cocoa Foundation Framework objects with "equivalent"
Carbon Core Foundation objects, i.e. pass them along between Cocoa and
Carbon code? If so, what special steps need to be taken?
Yes, no special steps are needed. In fact, for example, you can pass a
CFArray when an NSArray is expected, and vice versa, along with quite a
few other.
4) How easy or difficult is it to put a Cocoa front-end (i.e. User
Interface) on a Carbon based core?
It's quite trivial.
Would everything have to be done in PB or could the Carbon core be done
in CW and "exported" to PB/Cocoa?
You could go either way.
5) Did I forget an important question on this issue...
Other issues for us are:
1) How integrated multiprocessing and threading are in Cocoa?
Quite, and they're quite easy to use via NSThread.
2) How integrated AppleScript is in Cocoa?
3) How large the speed penalty under Cocoa is when working with extremely
large files and large numbers of objects (instead of plain data
records/structs).
I would guess that with a *huge* number of classes, there could be a
noticeable speed difference, but in such a case, I would probably
implement the backend in C++, and the UI in Objective-C.
--
Clark S. Cox, III
email@hidden
http://www.whereismyhead.com/clark/