[Openmcl-devel] more openmcl foreign ptr access issues
Gary Byers
gb at clozure.com
Tue Sep 14 00:31:58 PDT 2004
On Mon, 13 Sep 2004, Cyrus Harmon wrote:
> Following up on my own problem, the following does what I was looking
> for:
>
> (defmethod initialize-instance
> ((slotd mac-foreign-standard-direct-slot-definition) &rest all-keys
> &key direct-superclasses)
> (call-next-method)
> (if (and (slot-boundp slotd 'foreignp)
> (car (slot-value slotd 'foreignp)))
> (let* ((field (slot-value slotd 'foreign-field))
> (reader (compile nil `(lambda (r)
> (pref r ,(car field)))))
> (writer (compile nil `(lambda (r v)
> (setf (pref r ,(car field)) v)))))
> (setf (slot-value slotd 'foreign-reader) reader)
> (setf (slot-value slotd 'foreign-writer) writer)))
> )
>
> (There's probably a way to get both the reader and writer to play nice
> as an accessor that can be setf'ed, but I haven't gotten to that.)
>
The other approach that I was hinting at is used in the ObjC bridge.
Your approach has the advantage of making PREF do the work:
- if foreign type details change in the future, PREF should understand
how to deal with those changes
- PREF (supposedly) already knows how to deal with existing details, so
anything that goes wrong is PREF's fault.
The approach that the bridge takes (in COMPUTE-FOREIGN-SLOT-ACCESSORS,
in "ccl:examples;objc-clos.lisp") basically does a TYPECASE on the
foreign type and tries to select the function that PREF would have
probably macroexpanded into a call to. The primary advantage of that
scheme is probably that the set of distinct getters and setters is
likely to remain small (though there are some closures involved), e.g,
a thousand foreign slots would all use CCL:%GET-SIGNED-LONG to access
a foreign :INT, as opposed to each of them using a separate function
whose body (as determined by PREF) would basically be a "call" to
%GET-SIGNED-LONG. (It might also be a little faster than calling
the compiler, but this is happening at DEFCLASS time, so that's not
likely to matter much.)
There may be other approaches that neither of us is thinking of, and
at this point any approach that's understandable and works has a huge
advantage over any other approach ...
More information about the Openmcl-devel
mailing list