From: Guillaume Cottenceau <gcottenc@...>
Date: 2005-04-13T07:14:44+09:00
Subject: Re: ability to run finalizers at a given point of a program?

> > In other words, in my opinion there are cases where IO can be freed
> > with a try|begin/catch|rescue/finally|ensure but other cases where for
> > example an object is a wrapper around some IO, and in such
> > circumstances it makes good sense to free this IO when the object it
> > out of scope instead of explicitely calling a close/free method,
> 
> As I tried to explain in my last post you don't need to invoke the cleanup
> explicitely because you can encapsulate that in a method that takes a block.

As I tried to explain as well, let's try not to stay on the usual
"your algorithm is broken" answer, and consider the problem (you might
want to think you're considering a purely academic question, if that
helps).

Ok, since I know that no one will want to do that without a more
precise example, here it is: what happens when the resource is
allocated and worked on first, then in a totally different part of the
program, much later, results are extracted from it - and this
extraction can also possibly be performed multiple times, then again
later (laaaaaater) the object is collected? Does this block trick
still work? It seems not, if I understand it correctly. And, may I
add, the "destructor semantics" simply perfectly apply to such
circumstance. E.g. putting in the object's class itself some code to
be run when object disappears, whenever and on whatever circumstance
this is the case.

-- 
Guillaume Cottenceau - http://zarb.org/~gc/