Dan Sugalski wrote:
>
> [...] I wasn't talking about try{}/finally{} stuff. I was talking
> about DESTROY (or its equivalent) for objects, which unfortunately
> can't be tied to any one particular place in the code.
and, from another thread:
> I really don't want to guarantee predictable end-of-block cleanup,
> though, since that means a potentially expensive GC run more often
> than we might otherwise do.
Yes, and I agree with you. I'm just saying that if we're not going
to automatically guarantee predictable end-of-block cleanup, then I
think we need to provide some way for developers to explicitly
specify predictable end-of-block cleanup (using something like an
always block or finally clause). Since this explicit operation has
to deal with stack unwinding, and therefore with exception trapping,
this end-of-block cleanup operation has some eval-like semantics.
Therefore, a complete consideration of the matter of end-of-scope
includes not just (1) garbage collection, and (2) DESTROY, but also
(3) the matter of end-of-scope operations explicitly requested by
the developer, in an explicit order which may or may not be related
to GC or DESTROY order, and (4) the matter of the interaction between
explicit end-of-scope operations and explicit conditional exception
handling.
Jan Dubois wrote:
>
> Could you guys please use "destruction" or "cleanup" as the term
> for the end-of-scope processing (see e.g. C++). Finalization is
> used everywhere else to mean: called by GC before the memory is
> released (see e.g Java/C#).
Thanks for the reminder about the ever-present problem of
conflicting terminology. I was using "finalization" as a
generic label for various kinds of end-of-scope operations.
I'm not doing it any more ;-)
I think there are three concepts we need labels for, in order to
keep the discussion clear.
- Code automatically invoked just before an object is finally
garbage collected, whenever that actually happens.
- Code automatically invoked when an object is finally DESTROYed,
whenever that actually happens.
- Code automatically invoked when a block scope finally ends,
whether because of local flow-control or because of stack
unwinding.
These are all "end-of-scope" considerations, for various values
of "scope". They're all about answering the following question:
When the closing curly brace in { ...; my $p = P->new(); ... }
is encountered, what happens to the object referred by $p?
Yours, &c, Tony Olekshy
