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: Marcel Weiher <email@hidden>
- Date: Sun, 27 Jan 2002 11:27:23 +0100
On Sunday, January 27, 2002, at 10: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?
Cocoa already links against Carbon, so Carbon is always available from
Cocoa. However, do beware that using Carbon directly, instead of
through Cocoa, will diminish any cross-platform hopes (GNUStep etc.).
Best to keep those parts isolated.
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. None. You just call the function. You may have to include a
header, though Cocoa/Cocoa.h already includes Carbon headers (I don't
know how many).
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?
A shared library is easy, since Carbon itself is just a shared library.
Plugins also work, AFAIK, though this is not something I have tried
myself, but all the APIs are readily available and OmniWeb, for example,
apparently supports carbonized Netscape-style plugins.
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?
I don't quite know what you mean here. Carbon typically does not have
objects, being primarily procedural APIs. Most CoreFoundation objects
are transparently bridged to Foundation objects: for example, a
CFString *is* an NSString.
4) How easy or difficult is it to put a Cocoa front-end (i.e. User
Interface) on a Carbon based core?
This is impossible to say for the general case. I once did a small
Cocoa front-end to a Carbon newsreader core in about 8 hours.
Would everything have to be done in PB or could the Carbon core be
done in CW and "exported" to PB/Cocoa?
I don't know CodeWarrior, but would expect things to be easier if you
use PB consistently.
1) How integrated multiprocessing and threading are in Cocoa?
There is NSThread. The AppKit is generally regarded as non-thread-safe,
but this seems to have improved significantly in recent releases.
However, the official documentation on this is somewhat sketchy.
2) How integrated AppleScript is in Cocoa?
A mixed bag so far. The parts that are done are generally excellent,
but some parts aren't done yet. Typically, Cocoa will translate from
Apple Events to Objective-C messages for you automagically. See the
provided documentation. See also AppleScript Studio.
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).
Extremely large files are handled very well using Cocoa, for example
with NSData, which makes good use of the underlying, highly efficient
Mach facilities for virtual memory.
Large numbers of objects can be a speed-drain, though the main drain
will typically be memory allocation, which would be pretty much the same
for plain-data or records/structs. There are many ways to optimize such
overhead away when neccessary. If all else fails, Objective-C includes
all of C, so you can always revert to using plain data / structs for
time-critical sections.
Anyway, remember the rules of optimization by Michael Jackson :
[The First Rule of Program Optimization] Don't do it.
[The Second Rule of Program Optimization -- For exports only.] Don't do
it yet.
So, write your program in the simplest possible way. If there is a
performance problem, profile it to see what exactly is causing it. Once
there, Objective-C gives you enough capability to deal with the
problem. Also, since you'll be done so much more quickly, you'll have
more time to do real profiling/optimization instead of
premature/pointless optimization.
My 0.02
Marcel
--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.