[Openmcl-devel] Using Cocoa with MCL

[Gary Byers]

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
> > everything.
>
> 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
> > like:
> >
> > (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
> > defaults.)
> >
> > 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 conventions.
(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 is
> 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
   slot.

>
> > 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 functional
> 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, at
> 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 ?

>
> Randy
>
>
>

_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel