Dan Sugalski wrote:
> 
> Tony Olekshy wrote:
> >
> >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).
> 
> Attributes or other things stuck on the end of blocks strikes me as
> a messy sort of way to do this. Why not something simple like
> GC::cleanup or GC::collect, to explicitly cleaning up after
> destructable objects and collect garbage memory respectively?

Hmm, I think we still have a terminology impedence mismatch here.
It's probably my fault.  When I said "end-of-block cleanup",
I didn't just mean DESTROY and/or GC.  Consider the following:

    {    
    my $p = P->new;

    try { $p->foo } finally { $p->bar };

    $p->baz;
    }

There's an explicit end-of-block "cleanup" operation for the try
block, namely $p->bar, which is called whether or not $p->foo throws.
Then, iff neither $p->foo nor $p->bar throws, $p->baz is called.
Then (whether we're now unwinding or not) there's an end-of-block
cleanup operation for the anonymous block, but this an implicit
end of lexical scope cleanup for $p (not an explicit finally clause
or POST block), so if $p's object's refcount is 1, or it is found
in some sort of sweep, then DESTROY and garbage collection can be
considered.

Meanwhile, I agree that try/finally (or any similar such explicit
exception handling mechanism) is not an appropriate way to talk
about GC, more strongly, I think the two mechanisms should be
explictly decoupled.  (Personally, I don't think developers should
expect implict cleanup to be guaranteed to happen immediately,
and I don't think the Perl 6 designers should be so constrained,
but that's probably just because I've structured my code so as
to obviate the need, and therefore don't appreciate it.)

I only mentioned try/finally in the GC thread to note that if
we use a mechanism like that to handle explicit end-of-scope
problems, then you guys are free to do whatever you want with
DESTROY and GC, without having to worry about explicit end-of-scope
stuff.  You can design any high-quality scheme you want, and for
those cases where an explicit alternative is required, try/finally
(or equivalent) can be used.

I was trying to make your problem simpler, by punting one part
of it to the results of the try/finally effort.  Sorry for the
confusion.

Yours, &c, Tony Olekshy

Reply via email to