Re: 1.6.0 and guardians

[Dirk Herrmann]

On 5 Sep 2001, Michael Livshin wrote:

> well, I implemented the non-greedy variety because the greedy variety,
> while being better optimized for common usage, has some pretty ugly
> warts.

Which ones?

> > Further, there are (IMO) some weak points about the current
> > interface: Instead of having a throw_p parameter for the function
> > scm_guard, a separate scm_guarded_p predicate seems cleaner to me.
> 
> I considered this, but it isn't really any cleaner.  it's also not
> thread-safe -- the state of the world might change under you between
> checking whether the seat is taken and actually sitting down.

Yes, but this is something that can be taken care of on the user level, by
some user level mutex.

> > Destroying of guardians is also a functionality that I can't follow.
> 
> here's the rationale, from the NEWS entry:
> 
> <quite>
> Also, since greedy guarding is, in effect, a side-effecting operation
> on objects, a new function is introduced: `destroy-guardian!'.
> Invoking this function on a guardian renders it unoperative and, if
> the guardian is greedy, clears the "greedily guarded" property of the
> objects that were guarded by it, thus undoing the side effect.
> 
> Note that all this hair is hardly very important, since guardian
> objects are usually permanent.
> </quote>
> 
> note the use of "are usually" and "hardly very important".  without
> the presence of `destroy-guardian!', I would have to dictate a style,
> and I'd rather not.

Then I'd rather use an operation 'unguard' that unguards a single
object.  However, I don't even consider this as usefull.  Guardians are
used for sideeffects, namely to perform finalization actions, which can be
assumed to have sideeffects, because otherwise they wouldn't make much
sense.  And, it is always up to you what you do with an object returned
from a guardian:  If you during the lifetime of a guardian change your
mind and don't want to perform any finalization operations any more on
those objects, you can just retrieve them from the guardian and let them
be.

> > Finally, the fact that objects in cyclic dependencies are reported is
> > quite nice, but simply unguarding them seems wrong to me.  I can see
> > several possibilities to deal with such objects:  a) Return them from the
> > guardian as other objects and let the user deal with them, b) return them
> > wrapped in some special smob object to indicate their specialness to the
> > user (disallowing, however, to register such a smob with a guardian) c)
> > just keep them guarded forever d) have some special system wide list
> > for these objects where such an object gets transferred to if it is
> > detected - then the user can from time to time fetch out these objects and
> > decide what to do about them, like breaking the cycles.
> 
> I like variant d).

That's my preference also.

Friendly regards
Dirk Herrmann