I don't mean unset($this) is the best wy to allow an object to destroy itself. I just say we miss something to auto destroy objects.
We could also think about a magic method like __destroy().
An object that destroys itself is a really bad idea from an architectural point of view. I, as a consumer of your class, need to have control over the lifetime of any instances I create. In my opinion if you have a need for a class to destroy itself then you have a fundamental design flaw.
I want the object to be destroyed when a specific method of this object is called because when it has been called, the object has no reason to exist anymore.
It's like a SQL resource, when you have freed it, you don't need it anymore.
$my_object = new Blah();
$my_object->DoStuff();
....
unset($my_object);
As long as you don't have any references (as in these sort:
http://www.php.net/manual/en/language.references.php) to $my_object then
the memory will be freed.
I would like to implement it in order to delete automaticly from memory useless objects.
It can be really useful for example to make schedulers in PHP in order to avoid "max memory usage exceeded" errors.
Sprinkle your code with memory_get_usage() calls and see where your
memory is being used and concentrate on the areas with big jumps first.
php can definitely support long running scripts with an even amount of
memory used (mine run for 3-4 hours on a prod machine and use no more
than 6-10meg depending on data).
Another approach would be to use xdebug and profile your scripts and
concentrate on the areas that use the most cpu time because they'll
probably be the most called code.
http://xdebug.org/docs/profiler
--
Postgresql & php tutorials
http://www.designmagick.com/