[Openmcl-devel] Using Cocoa with MCL

[Eric Dahlman]

Howdy,

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

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

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

-Eric


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 
>>> generator.
>>>
>>> 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.
>
> h
>
>>
>>> Also while I'm dreaming, I'd like a pony.
>>
>> Is that a subclass of NSObject? :-)
>>
>> Randy
>
> No, NSPony is a subclass of NSImaginaryObject, a peer of NSObject.  I 
> think memory allocation is a little different for NSIOs.
> h
>
>
>
> _______________________________________________
> 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