[Openmcl-devel] Cocoa

[Gary Byers]

On Tue, 4 Feb 2003, Randall Beer wrote:

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

CLIM is a very interesting possibility.  I'd certainly like to see
a Cocoa backend for McCLIM (http://mcclim.cliki.net).  Tim Moore
and I bounced a few ideas back and forth a month or so ago; we should
probably revive that process and try to involve anyone else who might
be interested.  (McCLIM -does- run in OpenMCL, but uses CLX to talk
to an X Window server.)

I'm sure that CLIM would be very interesting to some people and almost
totally uninteresting to others.  A lighter weight middle layer might
be more interesting to people who don't want/need all that CLIM provides
(and might incidentally make developing the McCLIM backend a bit easier.)


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

One of the nice things about Apple's ObjC runtime is that it's possible
to ask it to enumerate all of the classes that currently exist and to
ask it what instance variables, class methods, and instance methods exist
for each class (and to get fairly detailed about instance variable types
and method signatures.)


> (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.

I think that it's a good thought.

I think that designing a good application framework is a hard problem;
I don't trust myself to do a good job of that (and don't trust too many
other people, either.)  Being able to leverage off of all of the design
work that's gone into Cocoa seems very attractive: I think that that
work's mostly very good and it's fairly easy to do the low-level hooking-
into-lisp stuff that needs to be done.

Some aspects of the memory syncronization problem may have simple
solutions.  I was talking with an MCL user about how to encapsulate
OSX Core Foundation objects in CLOS objects (CF objects are so similar
to NSObjects that it would seem that one's a fairly thin wrapper on
the other.)  We convinced ourselves that things would work correctly
if an encapsulating CLOS object retained the underlying CF/NSObject
when it was first created, that the encapsulating object involved was
marked for termination/finalization (via CCL::TERMINATE-
WHEN-UNREACHABLE) and the terminate method decremented the NS/CFObject's
reference count.   That might require some further thought, but I think
that it's probably sufficient to keep the NS/CFObject from getting
deallocated while we still hold a reference to it and to ensure that
they eventually do get deallocated.

I'm not entirely sure of the best way to translate ObjcC class
methods into equivalent CLOS methods (there may be a simple approach
that I'm just not thinking of.)  I suspect that you're right that it
wouldn't be too hard to apply some name transformation rules and
automatically wrap ObjC instance methods in appropriate CLOS methods.
We might need to think about how to map INITIALIZE-INSTANCE (and
ALLOCATE-INSTANCE ?) onto whatever set of allocation/initialization
methods

We presumably also have to do something so that methods specialized
on encapsulating CLOS objects are callable from foreign code, and
may or may not need to make CALL-NEXT-METHOD do [:super ...].

There are some problems to solve there, but at least some of them lend
themselves to automatic solutions.  (Some others obviously require
more thought, and some may require more MOP ...).  I like the idea
of keeping the CLOS interface as a thin and fairly direct wrapper
on top of Cocoa (with the reference counting and some other details
hidden), so that with a little bit of experience people could easily
translate ObjC Cocoa examples to fairly reasonable and readable lisp
code.



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


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