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: David Remahl <email@hidden>
- Date: Sun, 27 Jan 2002 11:56:20 +0100
>
On Sunday, January 27, 2002, at 03:52 AM, David Niemeijer wrote:
>
>
> 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?
>
>
AFAIK, most of the Carbon calls are C functions, so you should be able
>
to call them from any C variant, which includes all the above. You will
>
need to include Carbon.framework in your project, and you will need to
>
put #include (or #import) <Carbon/Carbon.h> at the top of your code.
Correct.
>
> 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'm not the expert on this, but it should be completely possible.
You can use the CFPlugin API, link to the libraries or build the code as a
framework. Framework is the best solution in most cases, I think.
>
> 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?
>
>
Don't know the answer to this one.
No necessary extra steps!!! Toll-free bridging. That means that NSString can
be exchanged for CFString, CFDictionary for NSDictionary etc and vice versa
without any speed penalty. For any function taking a CF-type, pass the
corresponding NS object. Translation comes for free. Not all NS-types are
toll-free bridged to CF though, but the essential ones are.
>
> 4) How easy or difficult is it to put a Cocoa front-end (i.e. User
>
> Interface) on a Carbon based core? Would everything have to be done in
>
> PB or could the Carbon core be done in CW and "exported" to PB/Cocoa?
>
>
Couldn't you just implement a bunch of methods in an object, each of
>
which called some function in your Carbon core, and wire the interface
>
elements to the methods?
Very easy. Check out IconFamily (
http://homepage.mac.com/troy_stepens/),
DisplayKit (sorry, no URL), MediaKit
(
http://www.sourceforge.net/projects/mediakit) and many others that have
already been done as frameworks.
>
> Other issues for us are:
>
>
>
> 1) How integrated multiprocessing and threading are in Cocoa?
>
>
Well, you have to use Distributed Objects if you want to do AppKit stuff
>
in the threads, since AppKit isn't thread-safe. If your threads just do
>
grunt-work, threading is pretty easy.
Very well integrated. Threading means a lot less problems in Cocoa than in
Carbon, but as always it does take some effort to get it right. Make sure
you use a good OO design.
>
> 2) How integrated AppleScript is in Cocoa?
>
>
Very. AppleScript Studio itself is really nothing more than a Cocoa app
>
with no Obj-C objects in it. Any Cocoa app can do anything AppleScript
>
Studio can do, AFAIK.
It is still a bit difficult to construct and send appleevents...I must admit
i'm not all up-to-date on ASS, but before it there were no Cocoa objects to
send appleevents.
>
> 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).
>
>
Someone else will have to answer this...
It can mean a considerable loss to work with NSData and the file access
classes in rare cases. For those cases, use BSD functions. Cocoa will allow
you to deal with 95% of the cases in no-time so you can concentrate on the
exceptions.
/ David Remahl