[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: class updating protocol
- To: common-lisp-object-system@SAIL.STANFORD.EDU
- Subject: Re: class updating protocol
- From: Patrick H Dussud <DUSSUD@jenner.csc.ti.com>
- Date: Fri, 29 Jan 88 08:11:20 CST
- In-reply-to: Msg of Thu, 28 Jan 88 11:51 PST from Gregor.pa@xerox.com
;;;; The class updating protocol.
I don't object to the principles of this protocol. I have some specific
comment here, and I sent some comments about reinitialize-instance earlier
this week.
;;;
;;; This is called when a class is reinitialized, and the dependent has
;;; been recorded as one of the dependents of that class. It is supposed
;;; to make sure the dependent class is updated to take the change into
;;; account.
;;;
(defmethod update-dependent :around ((reinitialized-class standard-class)
(dependent standard-class)
&allow-other-keys)
(let ((old-access-keys (class-access-keys dependent)))
(call-next-method)
(unless (equal old-access-keys (class-access-keys dependent))
;; Implementation specific code to account for the fact that
;; the access keys for this class have changed. This will
;; cause the optimization of standard-instance-access to
;; continue to work.
;; This may include a call to make-instance-obsolete.
)))
(defmethod update-dependent ((reinitialized-class standard-class)
(dependent standard-class)
&key direct-superclasses
direct-slots
direct-options)
;; When we are called, dependent is finalized since our finalize
;; inheritance method is what recorded us as a dependent. We
;; have to do whatever updating is required to keep us finalized.
;; This includes:
;; - recomputing our class-precedence-list
;; go through the old and new cpls, calling remove-dependent
;; and add-dependent to update our dependents.
;; - recomputing our slots, this may change the value that
;; class-access-keys will be returning.
;; - go through the old and new slots adding and removing
;; automatically generated reader and writer methods as
;; required.
)
Does update-dependent call update-dependent on its dependents, or is the
dependent structure flat? This probably needs to be specified.
(defmethod finalize-inheritance ((class standard-class))
;; When we are called, the class is supposed to not be finalized.
;; We are supposed to ensure that it is finalized, that an instance
;; can be created. But sometimes we are called redundantly. First
;; we check to see if we are already finalized, if we are, we do
;; nothing. If we aren't, we set cpl and slots to NIL and then call
;; update-dependent with only two arguments, each of which is the
;; class. Once update dependent returns, we set class-finalized-p
;; of the class to T.
)
Why does finalize-inheritance have to do its work by calling
(UPDATE-DEPENDENT class class)? It seems backward to me. Why can't
UPDATE-DEPENDENT call (FINALIZE-INHERITANCE dependent),
and FINALIZE-INHERITANCE do the slot and CPL computation?
Patrick.