Buddha Buck <[EMAIL PROTECTED]> writes:
> At 03:54 PM 12-06-2000 -0500, Sam Tregar wrote:
> >On Wed, 6 Dec 2000, Dan Sugalski wrote:
> >
> > > Non-refcounting GC schemes are more expensive when they collect, but less
> > > expensive otherwise, and it apparently is a win for the non-refcount
> > > schemes.
> >
> >Which is why GC is intimately tied to DESTROY consideration in terms of
> >Perl. If we intend to honor predictable DESTROY timing, and I think we
> >should, then we will need to reference count. No ifs, elses or
> >alternations. Anyone care to refute?
>
> This is not a complete refutation, but...
>
> It seems to me that there are three types of thingies[1] we are
> concerned about, conceptually:
>
>
> A) Thingies with no DESTROY considerations, which don't need refcounts.
> B) Thingies with DESTROY methods, but aren't timing-sensitive. They
> can be destroyed anytime after they die. These don't really need
> refcounts either.
>
> C) Thingies with DESTROY methods which need to be DESTROYed as soon as
> they die. These would seem to need refcounts.
>
>
> I think that distinguishing between B and C is a syntax issue out of
> scope here. Although B could be lumped with A if we could tell B and
> C apart, I'll assume that we must lump B and C together.
I wonder if a syntax wart like:
sub DESTROY : immediate {
...
}
wouldn't be a good idea. Only catch with this is with inherited
DESTROYs, compounded if Damian's RFC about hierarchically called
DESTROY methods gets accepted. Hmm... the more I think about it, the
more I think it would be a bad idea. Though it might be nice if the
programmer can use ' : immediate ' as a 'hint' that may not get taken
in the initial versions of Perl6...
--
Piers
