Some Lisp implementations do not call the generic function slot-boundp-using-class as part of executing the normal lisp slot-boundp for performance reasons.
The specific problem I ran into was inspecting objects in Elephant (a persistent DB) where the metaobject protocol does not allocate storage for slots but redirects (via metaclass override of slot-boundp-using-class and slot-value-using-class) queries to disk database lookups. In this case slot-boundp returned nil, but slot-boundp-using-slot was returning 't'.
An alternative approach (safer?) rather than modifying swank-mop and forcing always using the generic function, would be to write a swank-slot-boundp defun that is selectively implemented by specific backends with this problem. i.e.
#-allegro (defun swank-slot-boundp (object slot) (slot-boundp object slot))
#+allegro (defun swank-slot-boundp (object slot) (slot-boundp-using-class (class-of object) object (<lookup-slot-def> slot)))
Ian
Martin Simmons wrote:
On Mon, 30 Jan 2006 21:12:11 +0100, Helmut Eller heller@common-lisp.net said:
Delivered-To: slime-devel@common-lisp.net
- Ian Eslick [2006-01-24 03:39+0100] writes:
It's a minor enough change I figured someone who checks in regularly can update this and provide some judgement on whether there are likely to be any problems.
I committed that change and added the *-using-class functions to swank-mop. It seems to work for CMUCL, SBCL, and CLISP. For the rest, well, it may just work, or we will receive bug reports, or it doesn't matter enough so that nobody sends a bug report.
LispWorks's *-using-class methods work with the slot name, not the slot definition. I suppose we can finess that in the swank-mop layer.
BTW, what kind of object returns NIL from SLOT-BOUNDP but still has a slot value and how is a user supposed to access it?
__Martin