May 15, 2003

On the openmcl-devel mailing list there's a discussion about how to create a nice interface to OS X's Cocoa framework from within OpenMCL, motivated primarily by the desire to make it easy to develop nice Aqua GUIs.

Objective C is interesting because there's a lot of introspection that can be done at runtime--you can determine the class of an object, the methods it supports, etc., which makes it at least seem possible to create a very general interface that doesn't have to have hardcoded support for each Objective C class and method. Such an interface has already been developed for Python, the PyObjC bridge.

Gary Byers discusses a couple approaches to bridging the gap between Objective C objects and Lisp objects:

I want to try to keep this reply high-level and abstract, but can't resist the temptation to sink into the gutter (or at least some lower- level details) for a moment. I don't know if anyone's ever looked at the function OBCJ-OBJECT-P (in “ccl:examples;apple-objc.lisp”); it does a very, very good job of heuristically determining whether or not a given MACPTR is an ObjC object (and if so, whether it's an instance, class, or metaclass object and what its class is.) One might be able to artificially construct a MACPTR that passed these heuristic tests, but such a MACPTR would have to look so much like an ObjC object that the ObjC runtime would be fooled as well; for the sake of argument, anything that OBJC-OBJECT-P says is an ObjC object pretty much -is- an ObjC object. (If anyone's skeptical about this, note that it's also possible to make OBJC-OBJECT-P more paranoid than it currently is. If we don't want to make this (as) heuristic, we can also modify the FFI to -really- distinguish between :ADDRESS (arbitrary pointer) and :ID (pointer to ObjC object, or - perhaps more generally - "pointer to runtime-typed foreign object", which might also provide a way to deal with CFObjects.)

Suppose that CLASS-OF and TYPE-OF (and a few other things) knew (via OBJC-OBJECT-P) that the result of calling

  [[(@class “NSWindow”) “alloc”] “initWithContentRect:...”]

was an instance of the NSWINDOW class (in the CLOS sense as well as the ObjC sense.) In such a world, the result of doing:

  (make-instance 'nswindow :content-rect ...)

would be the same type of object (and interchangably recognizable as an NSWINDOW/:<NSW>indow instance to both ObjC and CLOS.)


I have to admit that I find the unified approach attractive, if only because in every book or movie I've ever read or seen that involves Parallel Universes, something bad invariably happens.

Posted by jjwiseman at May 15, 2003 10:48 AM
Post a comment

Email Address:


Unless you answer this question, your comment will be classified as spam and will not be posted.
(I'll give you a hint: the answer is “lisp”.)


Remember info?