Re: dependent update protocol

[Danny Bobrow <Bobrow.pa@Xerox.COM>]

I had originally proposed the property list scheme.  I claimed that properties
would have advertised names, and advertised meanings.  Interference of property
names would then be intentional, or a bug. 

For example, for class updating I had specified that the resulting arguments
delivered to all dependents would be a property list containing three flags,
:supers-changed :slots-changed and :options-changed.  Alternatively, the
specification might be that there were simply one flag, :changed, with value an
integer between 0 and 7 whose bits indicated the same changes. These flags could
be used by all dependents of the class to determine if they were interested in
the change.  For example, the class itself would be interested in any change, a
subclass might ignore options, and a class browser would ignore :slots-changed
and :options-changed.  

I want to write

(defmethod update-dependent
  ((dependent class-browser-element)
   (class standard-class) &key supers-changed &allow-other-keys T)
  (when supers-changed (recompute-my-browser-display dependent)))

The point I am making is that we cannot encapsulate the information that is to
be passed to dependents if we do not know the full set of dependents.  If the
properties are not advertised as part of the protocol for a particular class, I
don't see how a new kind of dependent could get any clue about what had happened
to the instance.  


On the other hand, there is absolutely no such restriction on the information
that before-reinitialization passes to after reinitialization, and I think in
that case the class-keyed property list might be OK.