I just wanted to correct my small example:
On Thu, Apr 28, 2005 at 05:00:53PM +0200, Robin Redeker wrote:> Robin Redeker writes: And with explicit resource handling (without timely destruction) it may be:
{ my $s = new CoolClass; ... destroy $s; }
This should actually be, to prevent the resource from leaking:
{ my $s = new CoolClass; eval { ... do stuff that may throws ... }; destroy $s; }
That's not necessary to prevent the resource from leaking. It's only necessary if you want to unconditionally destroy the object when control is leaving that block for the first time. You probably don't want to, since that means any outstanding references will now refer to a dead object.
If you don't have the destroy, and don't tag the object as needing expedited cleanup, then the finalizer *will* still be called. You just don't have any control over when its called.
> Not that big difference. And this is what we have with > refcounting/timely destruction:
{ my $s = new CoolClass; ... }
The latter example will destruct nicely if something throws.
Regardless of GC method, yes. The only question is when.
It's *really* important to note that I explained how parrot does GC -- that wasn't opening a descussion on redesigning the feature. Parrot doesn't have, and isn't going to have, a refcounting GC system. That's just not an option.
Parrot's got a tracing GC system triggered on demand by failure to allocate resources, explicitly by user code, or at regular intervals. Switching to a different tracing system than what's in now is doable. Switching away from a tracing system *isn't*. That'd require changing the entire source base, and just isn't feasible.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
