[[ reply goes to -internals ]]
OK. Let's clear it up all at once from start. Below is the lifecycle of an
object (in Perl). A reference is blessed, and an object is the result of
this blessing. During the object's life, several methods of it are called,
but independent of which are called, it continues being an object.
When the object goes out of scope, it isn't dead still. It will only be
unreferenced, so that the script/program has no way to reach the object.
Anytime after that, the object is destroyed, i.e. the DESTROY method of the
object gets called. This is tipically used to release resources associated
with it.
After the object has been destroyed, the GC (or anything else) can collect
its memory for use it to allocate other objects (or anything else).
reference
|
| (blessing)
|
|
| /|
| / |
V / | (call a
object <- | method
| \ | of the
| \ | object)
| \|
|
|
| (object goes out of scope)
|
V
unreferenced
object
|
| << DESTRUCTION >>
| (object has DESTROY called)
|
V
destroyed
object
|
| (object's memory is
| collected by the GC)
|
V
death
Is this all clear? Are we agreeing with this terminology? Is this right?
Now. What I was proposing was, allow the programmer to explicitly allow the
`DESTRUCTION' action of the diagram above, besides of it happening when the
object goes out of scope. This means that the object will be destroyed
(having its DESTROY called, what means freeing resources) and no more
methods can be called on it (note that `method call' is not allowed on the
`destroyed object' state).
Some misunderstandings:
1. If it has to be done explicitly, it will be like C++, where all objects
must be freed.
Wrong. If the programmer doesn't do it explicitly, the system will do it
(probably before the GC collects the memory), but there will be no
guarantees regarding WHEN it will be done.
2. You can do it by calling DESTROY.
Only calling DESTROY would allow further methods being called on the object.
And when the object would be collected, DESTROY would be called again, which
is 2 times DESTROY getting called. That's not what I propose.
3. undef $var does it already. Anyway it shouldn't be done if there are
other references to the object.
Right. undef $var does it already and will keep doing it. The issue that was
being discussed here was: if we don't use ref-counting GC, we'll have no way
to tell when it will be done. By having an explicit way of doing this, it
would be possible for a programmer to say ``I know what I'm doing, so just
do it NOW!''. Of course the programmer could be wrong and other references
to the object could exist, but hey, he's saying he knows what he's doing,
that's his own problem. Anyway, other methods being called on a destroyed
objects should throw an exception, so that he can know his code has bugs in
it and he should rethink if he really should do this nasty stuff.
4. Why should we bother destroying an object before GC does it?
To free system resources, like open files or database connections. Probably
the average program won't do it never, but programs that must open several
files sequentially (and would go out of resources if filehandles out of
scope don't get destroyed) could probably use it to guarantee the resource
(open file, not memory) has been freed.
I hope I could explain it well. Anyone has questions about it?
- Branden
