[Ecls-list] Class bug.

[Juan Jose Garcia-Ripoll]

On Sun, Oct 26, 2008 at 10:03 PM, David Brown <lisp at davidb.org> 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

Juanjo

(*) I have always thought the requirement that slot methods are
created from the direct slots and not from the effective ones is plain
stupid.

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28009 (Spain)
http://juanjose.garciaripoll.googlepages.com