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.
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.
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.
Anyway, that data flow analysis that was being proposed could well be used
to `avoid' or `delay' resource exhaustion in some cases. But I don't think
any guarantees should be given about when the DESTROY method of an object
would be called.
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. The problem
I see with this is what if a programmer calls DESTROY on an object that was
being used by others. The way I suggest to deal with this is set a flag if
the object was already DESTROYed. Then if any other tries to use it, it
raises an exception (dies) with a message about ``This object was already
DESTROYed.''. This flag could be used also to signal to the GC system that
the object already got its DESTROY method called, and it shouldn't be called
again. Just an idea, but...
- Branden
