[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
initialization meeting notes
- To: Common-Lisp-Object-System@SAIL.STANFORD.EDU
- Subject: initialization meeting notes
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Mon, 27 Jul 87 22:05 EDT
- In-reply-to: <870723180901.2.GREGOR@SPIFF.isl.parc.xerox.com>
Date: Thu, 23 Jul 87 18:09 PDT
From: Gregor.pa@Xerox.COM
In this message I try to summarize what we agreed at the meeting in
Boston.
Thanks for getting all this on-line. I see only two things to disagree
with here, so we should start putting our heads down and agreeing on the
next level of detail.
(defmethod initialize-instance ((obj object) &rest initargs)
;; The default initialize-instance method deals with setting the
;; values of slots from slot-filling-initargs and from initforms.
;;
;; The rules are that the leftmost initarg which is declared
;; as setting a slot (with the :initarg slot option) actually
;; does set it (or is it the rightmost?); and that slots which
;; are not set by an initarg have their :initform evaluated and
;; used to set them.
)
It's leftmost, because that's the way duplicated &key arguments work
in all other Common Lisp functions.
Actually there are two issues here:
(1) If the same initarg appears more than once in the initargs list,
the leftmost occurrence is used and later occurrences are ignored.
This is just consistency with &key and there's really no choice.
(2) If more than one initarg is defined to fill a given slot, and more
than one of these initargs appears in the initargs list, what happens?
Flavors takes the rightmost, but that's a misfeature. We should either
signal an error or take the leftmost. It's a one-line change to make
Flavors take the leftmost (it will be a few microseconds slower, due to
doing MEMBER of a one-element list instead of EQ, not enough slowdown
to matter). I like taking the leftmost better than signalling an error.
(defclass ship ()
((x :initarg :x)
(y :initarg :y)))
(defmethod initialize-instance :after ((s ship) &key startp)
(when startp (start s)))
(defmethod start ((s ship))
(with-slots ((s :use-accesors nil))
(if (AND X Y)
<start it up>
(error "Have to set X and Y before starting a ship."))))
(One line of the above has been uppercased, the only ASCII way to
highlight it.)
I hope this is an erroneous example, and you're not really proposing that
otherwise-uninitialized slots should be initialized to NIL.
the only serious problem has to do with arranging for the default
initarg value forms to be evaluated in the lexical environment of the
defclass. (Of course if environments were first class objects this would
be trivial...)
I thought we agreed that defclass would translate the initforms into
functions and at the metaclass level they would appear as functions. I
don't think we need a new way, besides lambda, for capturing lexical
environments. (Of course implementations are not required to make new
functions in all cases; especially in the case of constant initforms,
they will probably make a closure of an existing function.) This implies
that one cannot use metaclass protocol to recover the original forms
that appeared in the defclass. Maybe we didn't agree on this, I couldn't
find anything about it in my notes from the meeting. Can we converge
on this now?