At 10:12 AM 2/14/2001 -0300, Branden wrote:
>David Mitchell wrote:
> > James Mastros <[EMAIL PROTECTED]> wrote:
> > > ... do refcounting (or somthing like it) for DESTROY to get called at
>the right
> > > time if the class (or any superclass) has an AUTOLOAD, which is
>expensive.
> > ... the above seems to imply a discussion that you only need to do
>expensive
> > ref-counting (or whatever) on objects which have a DESTROY method.
> > However, since you dont know in advance what class(es), if any, a thinngy
> > will be blessed as, you always have to ref-count (or whatever technique is
> > chosen) just to be sure:
>
>I agree. Mixing ref-counting and whatever won't work (or will work and will
>be worse than only ref-counting). Either we stick with ref-counting (and
>maybe add something for breaking circular references) or we forget about
>this fallacy of having DESTROY called at a predictable time.
Perl's never been able to guarantee that DESTROY would be called at a
predictable time. Ever. Sticking with refcounts won't make that any better,
since that's what happens now.
The question isn't "will we keep predictable object destruction" since
generally speaking we don't have it. The question is "will it get less or
more predictable, and at what cost".
>Afterall, why do we need DESTROY to get called at the right time? Afterall,
>Java does live without it, and if Perl is supposed to run on the JVM, we
>won't have it there anyway! I think with .NET (Microsoft's C# VM) the
>situation is the same.
*) People like it
*) Scarce external resources (files, DB handles, whatever) don't get
unnecessarily used
*) People like it
*) Saves having to write explicit cleanup code yourself
*) People like it
>If resource exhaustion is the problem, I think we can deal with that when we
>try to allocate a resource and we get an error, then we call the GC
>explicitly (one or more times if needed) to see if we can free some
>resources with it. Resource exhaustion would be a rare situation (I think),
>and doing some expensive treatment when it happens is OK for me.
The point of DESROY isn't resource exhaustion per se, at least not anything
the garbage collector will care about, since it only cares about memory.
>Also, I think it would be valid for the programmer to explicitly say ``I
>would like to DESTROY this object now'', and have the DESTROY method called
>in that time, even if the memory would be reclaimed only later.
So you undef your object reference. If the object doesn't go away, it means
that something else probably still has a handle on it somewhere.
Plus there's nothing stopping you from having $obj->DESTROY in your own
code, though it may be inadvisable.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
