[Openmcl-devel] What is the state of the phemlock included with OpenMCL?
mikel at evins.net
Tue Aug 10 09:55:46 PDT 2004
On Aug 10, 2004, at 8:18 AM, Takehiko Abe wrote:
> mikel evins wrote:
>> I'm using HIView in Clotho.
> Ah, that's good.
>> It's higher-level than previous Carbon
>> approaches, but overall the process of building an application on
>> Carbon still involves considerably more low-level coding and more time
>> in the OpenMCL kernel debugger than doing it with Cocoa. If the Cocoa
>> bridge in OpenMCL didn't suffer from its current (temporary) problem
>> with breaking when binaries move from one minor OS version to another,
>> then Clotho would still be built on Cocoa.
> I see.
>> However, as I said, there are some advantages to Carbon. It's mighty
>> fast, for one thing. It's easier to wrap straight C calls in CLOS, for
> Even with HIView? hmm.. OK. Maybe I should try both HIView and
> the cocoa bridge some day. It's gonna be a huge headache in either
> way though. All my GUI codes depend on MCL's view system.
It's easy to call Objective C when you're using the Cocoa bridge, but
the advantage of Cocoa is also the disadvantge of Cocoa: it does a lot
of work for you, but it does that work for you by being organized into
relatively large, complicated Objective C objects that present
relatively simple interfaces. The most effective way to use Cocoa is to
learn how the features have been organized in Cocoa and use them the
same way an Objective C programmer would.
The disadvantage of Carbon is also the advantage of Carbon: Carbon,
including HIView, is a very large number of relatively simple and
low-level structs and functions, which is a lot more work and a lot
more grungy debugging of low-level C calls, but it also gives you a lot
more freedom to organize your API the way you want without sacrificing
efficiency. You can pretty much build whatever Lisp-friendly API you
want on top of the Carbon calls. If you try to build a very different
API on Cocoa the result will probably be clunky and inefficient,
because you'll be fighting the way that Cocoa wants things to be
organized. You'll have to keep track of lots of objects and protocols
and marshal lots of data between them to keep the Objective C objects
happy while maintaining your different API on top. In practice, I
think, nobody will do very much of that; the sensible thing to do with
Cocoa is just try to fit with the way its API is organized.
To get the same effect in Carbon that you can get in Cocoa, you have to
make many more foreign calls and manipulate many more foreign data
structures. (for comparison, Clotho 0.2 can load a text document and
display the window in 5 objective c methods totaling about 60 lines of
code; the current development version of Clotho 0.3 does the same work
in about 100 lines of code totaling 16 foreign calls to C code, and a
much larger number of foreign data accesses.
The comparison cannot be exact, because it's hard to be sure what to
count; the Cocoa code takes advantage of the fact that simply by
creating Cocoa objects you inherit a lot of event-handling and
message-passing behavior. In Carbon you have to expend more effort
explicitly creating and setting up event-handlers (you get some of them
for free, but you still have to explicitly create and install a bunch
of them using C calls).
The functionality is also not exactly the same: the Cocoa windows
provide more behavior with less code. Also, reading and writing the
data in the editor buffers is very simple to implement for the Cocoa
windows. It's a couple of short method implementations. Doing it using
the Carbon MLTE API is so complicated that I basically don't do it at
all; instead, I use the Common Lisp pathname and streams interfaces to
read and write files, use Carbon's navigation services to pose open and
save dialogs, and use the MTLE code only to get and set the contents of
the editor buffers.
More information about the Openmcl-devel