self in slot initializations

["David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>]

    Date: Tue, 21 Feb 89 16:29 CST
    From: vaughan@MCC.COM (Paul Vaughan)
    
    Does anyone know why flavor slot initialization forms are not
    executed in an environment in which self is bound to the object being
    initialized in New Flavors (7.2)?  This fact has greatly complicated the
    way I construct composite objects where a composite object creates its
    components and the components need to know who their parent is,
    especially when the purpose is to allow for a whole family of composite
    objects with interchangable component flavors.

I can think of two reasons:

1. The object doesn't exist yet while the slot initialization forms and
default-initargs are being evaluated, so there is nothing to bind SELF to.
The object can't be created before evaluating the default-initargs, since
one of them might control how the object is created (e.g. what area), and
it would be inconsistent to evaluate the default-initargs and slot
initialization forms in different environments.

2. CLOS doesn't do it that way, so making Flavors do it that way would have
created unnecessary portability problems for users writing programs in
Flavors and later migrating them to CLOS.

The initialization forms in DEFFLAVOR and DEFCLASS are just a convenient
abbreviation to be used in simple cases.  For full generality, you
should use a method.  That's a MAKE-INSTANCE method in Flavors or an
INITIALIZE-INSTANCE or SHARED-INITIALIZE method in CLOS.