[Openmcl-devel] Using Cocoa with MCL

[Hamilton Link]

First let me say that the current ObjC ffi is fine for me mostly 
because I don't have a lot of time to even consider making improvements 
to the inspector (although I do have a fairly large file of use case 
notes etc that I hope to turn into design specs for a new one before 
the sun explodes and burns the earth into a cinder).

If someone had enough spare time to contemplate improving the 
cocoa/lisp interface (presumably so that other people with lots of 
spare time could use the improved interface to build a nicer OpenMCL 
development environment, or bring lisp to the forefront of the game 
developer world? dunno.), my personal opinion is that it could only be 
called stupid if it wasn't done from public design documents in a more 
or less public code base.

I hold this opinion because I'm generally pretty opinionated, but also 
I think this is going to be a nontrivial project subject (ideally) to 
the demands of GUI builders and McCLIM porters and whoever else shows 
up to write code, and if someone puts it down I think someone else 
should be able to pick it up in the same spot to keep things moving 
forwards. Plus (perhaps more importantly) I think in this case having 
multiple slightly different ongoing efforts to do the same thing will 
be counterproductive, because in some cases it may result in 
tailor-made modifications to the ObjC FFI and I suspect we could split 
the FFI without trying too hard.

As a process note, I think a combination of openmcl-devel traffic and a 
section of the openmcl Wiki site devoted to ObjC would work well 
enough. If we can post a generally agreed upon approach (if we haven't 
already) and develop that into a design, that would make me happy -- 
maybe that means I should contribute to them.

I also should point out that if we look to the "Learning Cocoa" book, 
it has a rather extensive To-Do list application example. Getting the 
FFI wrappers to the point that we can code that and the other examples 
from that book in lisp would be _very_ cool, and would provide the 
effort with a reasonable amount of focus w.r.t. what features have 
priority.

h

On Thursday, May 8, 2003, at 02:49 PM, Randall Beer wrote:

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



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