Re: dependent update protocol

[Gregor.pa@Xerox.COM]

    Date: 20 Apr 88 16:08 PDT
    From: Danny Bobrow <Bobrow.pa>

Danny's message prompted me to realize that there was a minor ommission
in the protocol.  Specifically, the updated class should be passing the
actual reinitialization arguments to the update-dependent generic
function.

I think the way to think of this is as a mechanism which enables
objects, when they are updated, to pass special information to their
priviledged dependees describing how they were changed.  Unpriveledged
dependees receive no special information, they only receive the
reinitialization arguments which caused the update.

So for example, when a class is updated, any of its dependents can see
the reinitialization arguments which caused the change.  From those
reinitialization arguments the dependents can infer what they will about
how the class changed.  But, a specific class of class (a metaclass) may
provide some sort of special information to its priviledged dependents.
This might include things like a bit saying whether or not the order of
the class's slots changed or something.  Some metaclass may choose to
document the format and meaning of this information, but standard-class
does not do so.

This means that to write the kind of code you suggest you could do the
following:

(defmethod update-dependent ((class standard-class)
                             (dependent class-browser-element)
                             reinitargs
                             plist)
  (when (getf reinitargs :direct-superclasses)
    ;; The supers may have changed.  Check our local cache
    ;; to see if they actually have.
    ...))

You don't have access to the information in the plist because it is
implementation dependent, but you do have free access to the reinitargs.

The distinction between priviledged and unpriveledged information is
made clear by which plist the information is in.
-------