Home » PEAR » PEAR » Bug #1426

[2004-05-17 17:25 UTC] mjohnson at pitsco dot com

Description:
------------
When classes are "destructed" using the PEAR destructor mechanism, they are destructed in the order constructed, rather than the more intuitive (and similar to true OOP) reverse order.

In most cases this is not relevant. However, in trying to implement a tracing mechanism that logs function calls and their durations, the "destructors" are not called correctly. Other destructors still need tracing calls but the tracing class is already "destructed".

I realize PHP 5 adds true destructors but for the time being I'm stuck with PEAR. I think the correct mechanism can be implemented by reversing the order the "destructors" are called in _PEAR_call_destructors().

In the meantime, I'll figure out a workaround.

Thanks,
Michael

Reproduce code:
---------------
<?php ;
require_once('PEAR.php');

class MyClass extends PEAR {
function MyClass($id) {
PEAR::PEAR();
$this->_id = $id;
echo "Constructed $this->_id\n";
}
function _MyClass() {
echo "Destructed $this->_id\n";
}
}

$mc1 = new MyClass(1);
$mc2 = new MyClass(2);
?>

Expected result:
----------------
Constructed 1 Constructed 2 Destructed 2 Destructed 1

Actual result:
--------------
Constructed 1 Constructed 2 Destructed 1 Destructed 2

[2004-05-23 13:47 UTC] pierre at dotgeek dot org

"rather than the more intuitive (and similar to true OOP) reverse order."

Ah? FIFO is widely used in OO?

In this case, I failed to see your problem. Do you have a short script to explain it?

I'm not sure it's safe to change the behiavoir now. It could be a BC problem.

--Pierre

[2004-05-25 13:59 UTC] mjohnson at pitsco dot com

No, FIFO is not widely used, LIFO is. But PEAR's destructors are FIFO. The first object constructed is the first destructed. This has made for some pretty big headaches in my current code.

I believe my reproduce code demonstrates what I'm trying to show. If it is still unclear, I'll add something a bit more complicated, with nested classes.

I understand the BC problem. I just wonder if it really would be a problem. When I first started using PEAR destructors I naturally assumed they were LIFO. It took this logging project to tell me otherwise. And that means I've been working on bad assumtions all along. If the behavior can't be changed, I'd recommend at least updating the documentation to reflect the current behavior.

Thanks,
Michael