[Openmcl-devel] wrapping foreign objects in lisp classes

Dan Knapp dankna at accela.net
Mon Aug 16 14:27:13 PDT 2004

   The approach you describe is certainly a reasonable one.  Its 
disadvantage, if I
understand what you're doing correctly, is that code which uses it is 
never going to be
quite identical to code which uses an ordinary Lisp class (or struct).  
That may be
entirely acceptable, depending, I suppose, on whether you personally 
find it
sufficiently simple to program with.

   The most idiomatic way would be to use the metaobject protocol.  This 
is exactly what
metaclasses are for: Ordinary Lisp classes use the standard metaclass; 
foreign structs
could use a new metaclass of your own design.  Indeed, this is what the 
Objective C
binding does, so if you're up to the task of reading the source code, 
you could have a
look at that for ideas.

   Using the metaobject protocol doesn't avoid having to write the 
custom readers and
writers; you still need to do that.  However, you should be able to do 
it in such a way
that you only need to do it once instead of for every slot of every 

   Documentation on the metaobject protocol can be found at:


   I can answer part of your question about making setf use your own 
writer.  The
hyperspec doesn't point it out specifically, but if you want your 
writer to be called
"name", you can just do:

(defun (setf name) (value structure)
   (format t "~&I'm setting the slot NAME in the structure ~S to the 
value ~S."

   Except, of course, you want to replace that with code that actually 
performs the
setting, instead of just telling you about it.  The way this works is 
that the name of
the function is (setf name) instead of just name, and it'll be called 
any time you
invoke it as:

   (setf (name some-structure) some-value)

   On a different note, you probably want to look at OpenMCL's function 
pref, if you
don't already know of it, since it can be used with setf and may make 
your program


   (Hmm...  I need to see about finding some way to make permanent links 
the documentation.....)

-- Dan Knapp

More information about the Openmcl-devel mailing list