[Openmcl-devel] Using Cocoa with MCL

[Randall Beer]

> 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 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*?

> 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. 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)?

Randy


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