At 03:56 PM 2/12/2001 -0700, Tony Olekshy wrote:
>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,
We're probably not, though. I, for one, would rather have reasonably
predictable end of block cleanup, though if it's less complete than what
perl 5 does that's OK with me. (Meaning the compiler, through code
analysis, decides what should be cleaned up with the stuff its unsure of
left for later, or something like that)
>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.
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?
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
