[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

dependent update protocol

The combination of these two messages (sent respectively by Gregor
and by Danny earlier today) looks like the right thing, although I
suppose I ought to take the time to think about it harder before
agreeing with it for sure.

The only problem I noticed is the usual bug with mixins that use
call-next-method instead of method combination.  Because of the
way the default methods for before-reinitialization and
after-reinitialization are defined, and because there is no
ordering constraint that forces updateable-object to be least
specific in the class precedence list, it is possible for these
default methods accidentally to shadow real methods for those
generic functions.  The best way to fix this is to use method
combination to ensure that all the methods are called and the
value returned by each method is passed in as the plist argument
to the next method.  This might also help fix the bug where your
second example after-reinitialization method forgot to return
its result.  A worse way to fix it would be to put in a bunch
of (and (next-method-p) (call-next-method)) forms.