Re: "after" variable watchers

[Matt Armstrong <matt@rfc20.org>]

martin rudalics <rudalics@gmx.at> writes:

> I'd like to install the attached patch which expands on the existing
> variable watching mechanism in the sense that the variable whose value
> gets changed has already the new value assigned to within the body of
> the watch function.  Such a feature is useful when the watch function
> calls already existing functions which act upon the variable's new value
> in a possibly deeply nested fashion.
>
> Consider the following example: A user wants to set `right-margin-width'
> of a buffer and I want to decide whether that margin really fits.  The
> mechanism whether it fits would be nested in a common function that
> decides whether any decoration (fringe, scroll bar, margin) fits into
> any window showing that buffer based on the minimum sizes of that window
> and the sizes of the remaining decorations.  Passing a "this is the
> requested new value of the right margin" setting to such a function is
> awkward at the very least.
>
> Objections, suggestions, comments?

I haven't seen vary many truly useful designs based on such a mechanism.
It would be good to understand why.

I think the basic problem is that the "deeply nested fashion" you
mention is often quite complex, and many times ends up depending on
other variables that are not yet modified.

Consider your example: what if the new value for `right-margin-width'
makes sense only after some other variables are also changed.  Say,
variables controlling fringe or scroll bar width, etc.  If those
variables are set by code after `right-margin-width' then the "valid
right-margin-width" predicate would reject the value even though it will
soon be valid.

What we end up with is a situation where not only the final state must
be valid (from the point of view of the watch function), but all
transient states too.  I have personally found systems like this to be
difficult to deal with.

The solution I most often I see is designs based on "dirty" state, where
some point in the future code is triggered to validate state state.  For
that I think the current watch mechanism is sufficient to track which
variables have changed?