This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Dumping and restoring side-effects


Dirk Herrmann <dirk@ida.ing.tu-bs.de> writes:

> 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.

Right, in this view, the data attached to the SMOB type is simply an
implementation detail of how the generic refresh function executes.

> 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).

I think we agree.  I just hope we're all not missing something.

Greg

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]