[Openmcl-devel] Using Cocoa with MCL
lurk at twincitizen.net
Mon May 12 15:22:46 EDT 2003
I only read my Open MCL messages once every blue moon and I wish I had
been in on this one earlier. I'll try to keep up better ;-)
In reading over this thread one thing that is not being properly
appreciated is how easy it would be for us to leverage the Objective-C
runtime to do almost everything we would need to dynamically at
runtime. The only real problem is that it is not necessarily possible
to "retract" a definition once it has been made. So here is my two
First a caveat there is a long raging religious war in the Objective-C
world over some of the stuff I am going to talk about. I don't have
the time to properly add all the disclaimers so keep in mind that I am
assuming Apple's implementation in everything and don't go a flaming on
those sundry things.
* Posing and Proxy Objects
In Objective-C there is a neat idea of a forward invocation where you
can create and object that poses and another. That object may then
choose to handle a message sent to it in any number of ways including
forwarding it to another object or whatever. For most practical
purposes that would allow us to create a single LispProxy class that
could receive any Objective-C message forward it to a Lisp Object for
processing. The Objective C side would be happy and need never know
A method invocation includes a pointer to the selector object so it is
easy to key off of this to identify the implementation on the Lisp side.
* Subclassing NSWindow and the like
Again subclassing is just a question of message forwarding. A new lisp
subclass would only handle those message it specialized anything else
would be forwarded to an instance of the Objective-C base class.
Objective-C is built with this idea in mind and it should work fine.
It is easy to extend the class hierarchy at runtime so we can
programmatically define new Objective-C classes and methods as need be.
* Interface Builder and Nibs
This is really easy because all that a nib is is a collection of
serialized objects. There just has to be a properly named class that
can read the serialization for them to be read in. That means that
what you have in Interface builder need not match what you have in
reality. If a outlet is not defined you will get an error when the NIB
is read in but that is it. So interface builder actually does not need
to be able to generate any lisp code for it to be useful.
One could make a class MySpiffyLispThingy in Interface builder and as
long as there where proper setFoo methods proved for the outlets you
defined in interface builder in you lisp code it would just work. All
that code generation gets you is a bit of convenience in that you won't
have any typos in the names.
I am kind of pressed for time now so I'll have to cut this short but
really if we leverage all the goodness that Objective-C give us we
could have a clean interface to almost Everything Cocoa offers in a
handful of foreign function calls an a couple of macros.
Now lets talk about my copious spare time...;-)
On Monday, May 12, 2003, at 01:08 PM, Hamilton Link wrote:
> On Thursday, May 8, 2003, at 06:51 PM, Randall Beer wrote:
>> On Thursday, May 8, 2003, at 05:34 PM, Hamilton Link wrote:
>>> One more thing -- it would be nice to be able to use the Interface
>>> Builder. If we do build a super-fancy wrapper around all of Cocoa,
>>> it would be nice to get Interface Builder to automagically generate
>>> a portion of the necessary lisp code based on me (or whoever)
>>> claiming to make subclasses and Outlets, etc.
>>> I don't know if this is possible, mind you, but I got the impression
>>> that it was possible to define new dialects for the boilerplate
>>> Also I am under the impression that it's possible to define new
>>> custom widgets under Cocoa that do various fancy things, like radio
>>> dials or whatever. Being able to dynamically pull in such a library
>>> (defining a new widget class) and build the lisp wrapper code for
>>> them would be good, if we don't get it for free, which we might if
>>> we do this properly.
>> If a (semi)automatically generated Cocoa interface were done
>> properly, then nib files and new Cocoa classes should be loadable. I
>> don't know offhand what would be involved in getting Interface
>> Builder to generate Lisp code, but that wasn't quite what I had in
>> mind. It might be an option, though.
> Seems like Interface Builder will probably always want to generate NIB
> files that refer to ObjC classes it thinks exist. There's a number of
> ways I can think of we might address this, none of which are probably
> easy, maybe someone else has a better idea...
> 1) Set up lisp to automatically revamp NIB files to refer to the
> lisp-mapped objc classes (this is probably easy enough to do). The
> problem is all the outlets and connections you'd like to set up with
> IB won't really be set-upable, so what about
> 2) Based on specialization in lisp's world, create an ObjC library
> file (or several) that can be added to an IB project that will tell IB
> about all the potential connectors and classes it can generate NIB
> files for, have the NIB files generated with all this information, and
> have Lisp take over the loading process. This doesn't seem very
> rapid-prototype-supportish to me since you have a lisp development bit
> that has to preceed any IB use, so what about
> 3) Based on specialization and addition of outlets, etc. in IB, have
> it generate lisp code (rather than java or objc etc, i.e. we'd define
> a new dialect) and NIB files that openmcl can use to extend the lisp
> class hierarchy, plug in to the right places in ObjC, and manage the
> NIB loading process. I don't even know if this is possible, but it
> seems like the ideal situation we could strive for.
>>> Also while I'm dreaming, I'd like a pony.
>> Is that a subclass of NSObject? :-)
> No, NSPony is a subclass of NSImaginaryObject, a peer of NSObject. I
> think memory allocation is a little different for NSIOs.
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
Openmcl-devel mailing list
Openmcl-devel at clozure.com
More information about the Openmcl-devel