[Openmcl-devel] What is the state of the phemlock included with OpenMCL?

[mikel evins]

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
>> another.
>
> 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.

--me