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/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
