Re: :accessor-prefix bug

[kempf%hplabsz@hplabs.HP.COM]

> reasons.  In the case of adding slot, with slots causes a new binding
> for some symbol.  Something like:

>   (defclass foo () (a))

>   (defmethod bar ((foo foo))
>     (let ((b :value-i-expect))
>       (with-slots (foo)
>         . . .)))

Within the WITH-SLOTS form, B is a lexical variable


>   (defclass foo () (a (b :value-that-breaks-my-code)))


Now FOO has a slot named B.

> (defmethod bar ((foo foo))
>   (let ((b :value-i-expect))				
>     (with-slots ((foo :prefix foo-))
>       ...)))

Yes, this would prevent it. But your argument implies that one should
*always* use the :PREFIX option, otherwise, this could happen in any
case where a lexically scoped slot name could shadow an outer lexical
variable. The same thing happens with lexically nested LETs, but
because the cause of the change is usually local (unless the outer LET
block is large) there is less of a problem.

I don't think the problem here is so much with whether or not to use
the :PREFIX option as with the semantics of WITH-SLOTS. In Smalltalk,
CommonObjects, and other languages with "instance variable" like
slot access, the slot name variable is privilidged within the scope
of the method, and trying to rebind it results in an error. But this
doesn't fit very well with Common Lisp's lexical scoping rules, and
not at all with multimethods. So perhaps the solution is to provide
a warning message at compile time if WITH-SLOTS tries to shadow an
outer lexical variable. Our compiler does something similar with
identifiers which are not declared SPECIAL and not lexical variables,
and we have had a request from some of our developers to do the same
with WITH-SLOTS.

		Jim Kempf	kempf@hplabs.hp.com