At 11:17 AM 12/7/00 +0000, Piers Cawley wrote:
>Buddha Buck <[EMAIL PROTECTED]> writes:
> > 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...
I think I'd just as soon always call DESTROY in a predicable manner and not
do *anything* perlish at GC time. If nothing else it means that we don't
have to worry about having a valid perl context handy when the GC runs.
(Since threading the thing is a possibility we might run into issues otherwise)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
