Re: Dumping and restoring side-effects

[Dirk Herrmann <dirk at ida dot ing dot tu-bs dot de>]

On 4 Feb 2000, Greg J. Badros wrote:

> I'm confused how this makes things *easier* on the ordering problem.
> The way I see it, if I have a list of objects that need to be freshened, 
> I can just go through the object in-order and call their freshening
> method.  If I have separate lists, one for each SMOB type, then I need
> to coordinate the order in which I call the freshen methods in some
> other way.

The point is, that it may or may not be important that all objects are
refreshened in order.  It might be, for example, that it is sufficient to
make sure that the X-server font information is updated before any color
changes take place (probably a stupid example by someone who does
not know what he is talking about).  In such a situation, it could make
sense to order the objects by type, although I can't give an example on
why this would make sense.  It's just possible :-)

But even if all freshening has to be done in a fixed order, there would
still be only need for a single list of objects, ordered according to the
required refreshening order.  A generic 'refresh' function is applied to
each element of this list.  Each type that requires refreshing extends the
generic 'refresh' function, thus keeping the implementation of the refresh
function at the point where the type is defined.

But probably I'm just stating the obvious and this is what you meant with
the following paragraph:

> W.r.t. flexibility, I don't think it's necessary to be able to call an
> arbitrary thunk, but it'd be easy enough to let procedures be added to
> the list of objects-neeeding-freshening, and just apply those elements
> when they are reached (i.e., the freshen routine for a procedure object
> is just a routine that invokes that procedure).

Best regards
Dirk Herrmann