[Openmcl-devel] Using Cocoa with MCL

[Randall Beer]

> The premise is that we have, for example, an LispMappedNSBrowser class 
> that is a subclass of NSBrowser and overrides all specializable 
> functions to call back into lisp with the appropriate information. If 
> lisp wants to interfere, great, otherwise the default is to call back 
> out into ObjC and invoke the super's method (the original NSBrowser's 
> functionality). Possibly we could optimize unspecialized calls to not 
> do this, but that's an implementation detail -- if it acts this way 
> but doesn't work this way at all, who am I to care?
>
> In any case, when you make instances of ns-browser in lisp (or in fact 
> any subclass of the lisp ns-browser class), you're making an object 
> that in turn makes a LispMappedNSBrowser in the ObjC run time, keeps a 
> reference to it and, in some global lisp hash table, maps the ObjC 
> instance back to the new lisp object. When the ObjC object is 
> manipulated via known Cocoa framework functions defined on NSBrowser, 
> these are specialized, call back into lisp, map from the ObjC world to 
> the lisp world, invoke a method on the lisp object, which delegates or 
> propagates all of it's changes back into the ObjC world using the 
> super's methods (the real methods on NSBrowser itself).

That's pretty much what I had in mind.  I don't see any way around this 
kind of mapping back and forth between the two worlds if we want a CLOS 
hierarchy that parallels Cocoa (although, as you say, some 
optimizations should be possible, such as only changing an ObjC method 
to call back into Lisp when there is a corresponding Lisp method 
defined).  Of course, there are numerous other implementation issues 
here (e.g., memory management, (semi)automatic name translation, 
exception handling, automatic type translation and checking, expanding 
something like (send w :set-title "My-Window') to (set-title w "My 
Window") so generic functions can be defined, etc.)

But what I'm looking for right now is some sense of what people would 
find most useful.  For you, it sounds like the current interface is 
fine, but I get the sense from other discussion on this list that 
others may disagree.  Would a little more syntactic sugar around the 
current approach be enough to make it more generally useful?  Is 
getting Cocoa objects into the CLOS world necessary?  Or is a complete 
nonCocoa CLOS layer required?

Suppose that someone was stupid enough to be thinking spending some 
time improving the Cocoa/Lisp interface.  What would be the best design?