beer at eecs.cwru.edu
Tue Feb 4 20:55:58 EST 2003
> 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.)
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")
[[(@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
Just a thought.
Openmcl-devel mailing list
Openmcl-devel at clozure.com
More information about the Openmcl-devel