PEAR destructors

Att: Stig (among others) Christian Rishøj wrote: > This leads me to the conclusion, that _after_ the contructer has run, a > _copy_ of the object is returned by the 'new' command. Therefore the > reference in $array is not a reference to the object returned by 'new foo'. This might seems a bit off topic, but the problem actually applies to the emulated destructors in PEAR as well. Let's see.... If a derived class in PEAR calls the PEAR contructor from its own constructor, the PEAR constructor will add a reference to the object being instanciated to a global array: /** * Constructor. Registers this object in * $_PEAR_destructor_object_list for destructor emulation. */ function PEAR() { global $_PEAR_destructor_object_list; $_PEAR_destructor_object_list[] = &$this; if ($this->_debug) { printf("PEAR constructor called, class=%s\n", get_class($this)); } } However, right after being instanciated, the 'new' operator returns a _copy_ of the object, meaning that when the _PEAR_call_destructors() is called, the actual object being destructed is not the same as the one returned by 'new'. While the object being detructed is not the same as the one that you have used in your script, this implies for an example that connections opened by the object after being instanciated won't get closed. If someone does not prove me wrong, this implies that the PEAR destructors are not very useful for e.g. database objects which makes a connection after being instanciated and relies on this being closed by the destructor, as the object being destructed doesn't have a clue of any connections made. Please consider this and share your thoughts. I hope someone will prove me wrong or enlighten me with a solution, partly because I would really like to make use of the PEAR emulated destructors, partly due to the fact that I am using the same concept in a current project of mine. /Christian