On Sun, Oct 26, 2008 at 10:03 PM, David Brown <lisp@...> wrote:
> The following code provokes an unusual bug in ECL:
> (defclass parent ()
> ((slot :reader parent-slot
> ;; Putting this in, eliminates the failure.
> ;; :allocation :class
> (defclass child (parent)
> ((slot :allocation :class :initform 64)))
> ;; Failure.
> (parent-slot (make-instance 'child))
> It seems to be a problem if the parent class has an instance
> allocation of the slot, and it is overridden by a class allocation in
> a subclass.
Argg, another subtle bug. We have a real problem here. Basically the
situation is as follows. The AMOP specifies that the slot readers and
writers are created from the direct slot definitions (*). Among other
important consequences, this means your second defclass, which does
not specify a :reader slot option, does not trigger the creation of a
slot reader method for SLOT. OTOH, the previous definition of SLOT
declared it having :INSTANCE allocation and thus ECL created an
optimized slot accessor. The result: you are calling an optimized
accessor with a class that does not have that slot.
A simple proof that this is the case: (slot-value (make-instance
'child) 'slot) works.
Well, probably nobody here cares about the details :-) but this is a
real problem. Basically it is telling us that we cannot produce
optimized slot accessors because any slot can have the allocation
class changed. Or maybe I am just wrong
(*) I have always thought the requirement that slot methods are
created from the direct slots and not from the effective ones is plain
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28009 (Spain)