[Openmcl-devel] Using Cocoa with MCL
Sven Van Caekenberghe
sven at beta9.be
Fri May 9 07:46:32 UTC 2003
I found the following docs on my Mac OS X system with dev tools:
I didn't have time to read it though ;-)
Also, have a look at the directories /Developer/Java/Jobs and
/Developer/Java/Headers, this is part of there autogeneration stuff, I
On Friday, May 9, 2003, at 04:57 AM, Gary Byers wrote:
> On Thu, 8 May 2003, Randall Beer wrote:
>>> Someone (perhaps Randall) pointed out that it's possible to peer
>>> into the ObjC runtime and find all classes; an ObjC class keeps
>>> track of its methods and their signatures, so it might be possible
>>> to automate the generation of procedural CL wrappers around
>> Yes, if we decide that a middle layer is best, I'm still thinking in
>> terms of generating this middle layer as automatically as possible.
>>> Suppose at this procedural level it was possible to say something
>>> (cocoa:init (cocoa:class-alloc *nswindow-class*)
>>> :content-rect r ; details, details
>>> :defer nil
>>> :style-mask (logior ...))
>>> e.g., there's a predictable one-to-one correspondence between an
>>> ObjC method and a functional lisp interface to it (and hopefully
>>> that functional lisp interface to it looks better than my example.
>>> Some keyword arguments are elided from the example above, more
>>> to save myself some typing than because I can think of plausible
>>> Presumably, the implementation of NSWINDOW-INSTANCE-INIT is
>>> very little more than some FFI gunk; the immediately obvious
>>> advantage of this scheme is that we don't have to read or write
>>> that FFI gunk ourselves.
> It might have helped if the example had used consistent naming
> (See how important that is ?)
>> It wasn't clear to me from your example whether you were thinking in
>> terms of a functional Lisp interface to ObjC or whether you were
>> thinking in terms of CLOS classes. Specifically, what kind of thing
>> the value of *NSWINDOW-CLASS*?
> Good question. There are (maybe) around 4 possibilities:
> 1) A raw MACPTR to a class object, pretty much as exists now.
> 2) A raw MACPTR with some extra bits that assert that it's an ObjC
> object (and that it's worth trying to ask ObjC what kind of
> object it is.) The Apple ObjC runtime allows for a lot of
> introspection and it seems to be pretty robust and reliable;
> if Apple keeps going in this direction, they'll eventually
> invent lisp ...
> 3) A lisp object (with a small "o") that encapsulates the underlying
> ObjC object in some way, but doesn't provide much OO behavior.
> 4) A fullblown CLOS object, which maybe has one of the above in a
>>> Whatever the high-level solution(s) turn out to be, it doesn't seem
>>> likely that the middle layer (the functional/procedural interface)
>>> will design itself. If the goal is to derive large parts of that
>>> middle-layer automatically, we have part of what we need (the ability
>>> to ask ObjC for all foreign method names and signatures); the part
>>> that's missing is a policy that'd guide that translation process.
>>> As an example: suppose that there's a Cocoa method that returns an
>>> :<NSR>ange structure. The way that structure return is implemented
>>> in most C compilers is that the caller allocates a structure and
>>> passes a pointer to it as an invisble parameter to the callee; the
>>> callee just fills in its fields. This is exposed in the FFI-based
>>> Cocoa code; would we want it to be exposed at a middle level ? I
>>> can think of arguments pro and con, which suggests that there may
>>> be more than one level in the middle ...
>> I think it should be consistent. Either we go for a layer of
>> syntactic sugar, which makes manipulation of ObjC objects easier and
>> more convenient (e.g., memory allocation), or we build a CLOS layer
>> which uniformly replaces ObjC objects with CLOS objects.
> I was thinking that for some things (very low-level event handling,
> for instance) it's desirable not to cons much, especially where nothing
> interesting's going on. We can always use the FFI to write the
> very low-level stuff like that, and keeping the number of middle layers
> small (0 or 1) seems desirable ...
>> As you
>> suggest, the latter may be implemented in former. I guess that I'm
>> struggling to clearly envision what the final goal should look like,
>> least in broad terms. Then we can decide what the right intermediate
>> layers of abstraction might be. Is the goal (1) Lisp sugar for ObjC,
>> (2) CLOSified Cocoa, (3) an MCL-like CLOS system, (4) something like
>> CLIM (or (5), something I haven't thought of)?
> What I'm thinking of as "the middle layer" might also be described
> as (1). I think that it'd be a step up from the status quo; it'd
> make things like the demo IDE easier to write and (hopefully) easier
> for people to understand. I don't know that CLOS needs to be too
> involved in things at this level. This layer might wind up being
> similar to CLX or XLib in scope: it's possible to program in it,
> but it's also useful as a foundation for higher-level things (McCLIM
> and other things use CLX, GTK/GDK/GNOME and Qt/KDE use XLib.)
> One place where that analogy breaks down is that CLX and traditional
> Carbon are "toolkits", whereas Cocoa (and modern Carbon, to a lesser
> extent) are "frameworks" : the toolkits provide drawing primitives
> and event notification, while the frameworks additionally provide
> reasonable default behavior and a protocol for extending it.
> In something like MCL's window system, CLOS provides the framework
> on top of the Carbon toolkit. What would/should CLOS provide for
> Cocoa ?
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
Sven Van Caekenberghe - mailto:sven at beta9.be
Beta Nine - software engineering - http://www.beta9.be
.Mac - svc at mac.com - http://homepage.mac.com/svc
Openmcl-devel mailing list
Openmcl-devel at clozure.com
More information about the Openmcl-devel