[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
self in slot initializations
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.