[Openmcl-devel] Cocoa

[Randall Beer]

> I think that the examples show that it's possible to write fairly
> interesting Cocoa programs without writing a whole lot of code.
>
> I think that the fact that the examples have pretty much stood
> still for several months might indicate that there needs to be a
> layer or two above the reader macros and glue that exist now.
> (It's neat to be able to write code in what looks like a hybrid
> of lisp and ObjC syntax, but I'd like to be able to write lisp
> code that provided a user interface and ignore all of the low-level
> details of dealing with the ObjC/Cocoa runtime.)

Gary,

I strongly agree that it would be very nice to have a Lisp layer over 
the details of ObjC/Cocoa. What do you think the best way to structure 
such a layer is?

CLIM is obviously one possibility.  Another possibility is something 
like the view, window, etc. classes in MCL reimplemented in Cocoa.

I've been wondering if there might not be a way to automatically 
provide a Lisp "mirror" for Cocoa.  The idea is to use the parsing of 
the Cocoa interface files that is already done to define a set of CLOS 
classes and methods that parallel those in Cocoa.  If this could be 
done, then we could write something like

(setq w (make-instance 'NSWindow))
(setTitle w "My Window")
(makeKeyAndOrderFront w)

instead of

[[(@class "NSWindow") "alloc"] "init"]
[wptr "setTitle:" :address (%make-nsstring "My Window")]
[wptr "makeKeyAndOrderFront:" :address (%null-ptr)]

There are obvious case issues here.  Perhaps a method of the form 
"makeKeyAndOrderFront" could be automatically turned into a Lisp-style 
symbol such as MAKE-KEY-AND-ORDER-FRONT, "setTitle" could be 
transformed into SET-TITLE, etc.

Making this work would require that any Cocoa mirror object inherit 
from a special NSObject CLOS class and possibly some MOP programming.  
The key thing would be that defining a new CLOS class that inherits 
from an existing mirror object would create the necessary ObjC class 
structure, making an instance of one of these Cocoa mirror objects 
would create the corresponding ObjC instance structure. Defining a 
method on one of the mirror classes would create an ObjC method in the 
corresponding ObjC class, accessing a slot in a mirror object would 
return a corresponding Lisp object, etc.

Undoubtedly, there are many difficult issues that would have to be 
addressed to make this work.  For example, how to keep the memory 
allocation and deallocation syncronized between Lisp and ObjC?  The 
advantage would be that this mirror approach, if it were feasible, 
would bypass the effort involved in writing an entire CLOS interface to 
Cocoa and would automatically inherit new features as Apple releases 
them

Just a thought.

Randy


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