dependent update protocol

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Wed, 20 Apr 88 10:00 PDT
    From: Gregor.pa@Xerox.COM

	Date: Mon, 11 Apr 88 15:50 EDT
	From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

	Also, since the style you propose depends on three methods for three different
	generic functions to be kept in sync, and does something unpredictable without
	necessarily signalling an error if one of the methods is left out, it doesn't
	seem very robust.  I would prefer to see either a more abstract data structure
	than a list, so that leaving out a method (or forgetting to call cdr) for one
	class would not damage the data seen by other class's methods, or else to use
	one generic function instead of three, so that all the code for one class would
	be in a single place and hence less likely to be out of sync.  In the latter
	case, this generic function would be called multiple times and one of its
	arguments would indicate whether state was being collected or
	distributed.

    I think these might be good ideas.  Unfortunately, in the abscence of a
    specific proposal for how to make this work I think we are going to make
    only the two changes described in this message.  We don't have the time
    to figure out how to incorporate this comment given that what we have
    will clearly work.

And will clearly break if misused.  Here's an idea: someone, I forget
who, suggested using a property list as the state that's passed around,
instead of letting each class's methods decide how they are going to
encapsulate the next class's state.  If you do that, then methods
getting out of sync cannot cause any damage.  The only way for one class
to damage another would be for both to use the same property name, but
the property names can be class objects.

Let me know if this is not a specific enough proposal and I'll somehow,
I don't know how, find the time to write it up more clearly.