#27555 [Com]: Unable to modify $_SESSION from __destruct()

From: Date: Thu, 08 Jul 2004 03:17:31 +0000
Subject: #27555 [Com]: Unable to modify $_SESSION from __destruct()
References: 1  Groups: php.doc 
Request: Send a blank email to phpdoc+get-969361752@lists.php.net to get a copy of this message
ID: 27555 Comment by: mikey-spam at mookins dot com Reported By: jaanus at heeringson dot com Status: Open Bug Type: Documentation problem Operating System: Linux 2.4.24 PHP Version: 5CVS-2004-03-10 (dev) New Comment: I am on Windows 2000, using PHP5 RC3. Having same problems. I also believe that the modules should be shutdown after __destruct() I am wondering if this is going to be fixed or is it not being classified as a bug? helly@php.net seems to think it's expected behaviour but I never thought it would be which is why I am here after googling about it. __destruct() is a user definable method. All aspects of user programs should have all the resources available to them from the start of the script right through to the end. Refcounting of whatever it was that they suggested is not an option, in fact, I don't even know what that is. -Mikey Previous Comments: ------------------------------------------------------------------------ [2004-06-15 11:07:03] dcaironi at yahoo dot com I agree with fschaper. The ability to modify the $_SESSION variable in the destructor could be very useful, for example to have your class automatically serialized in session; this, with a factory pattern (getInstance method, that unserialized the class if exists in session), allow to have a "session object", sort of. for example Class Test{ function __destruct(){ $_SESSION['test'] = serialize($this); } static function getInstance(){ $instance = unserialize($_SESSION['test']); if(!isset($instance) || !is_a$instance,"test")){ $instance = new Test(); } return $instance; } } Actually, this was possible with php 4.x using register_shutdown_function, that (in fact) allows to simulate the destructor behaviour... ------------------------------------------------------------------------ [2004-06-15 11:06:59] dcaironi at yahoo dot com I agree with fschaper. The ability to modify the $_SESSION variable in the destructor could be very useful, for example to have your class automatically serialized in session; this, with a factory pattern (getInstance method, that unserialized the class if exists in session), allow to have a "session object", sort of. for example Class Test{ function __destruct(){ $_SESSION['test'] = serialize($this); } static function getInstance(){ $instance = unserialize($_SESSION['test']); if(!isset($instance) || !is_a$instance,"test")){ $instance = new Test(); } return $instance; } } Actually, this was possible with php 4.x using register_shutdown_function, that (in fact) allows to simulate the destructor behaviour... ------------------------------------------------------------------------ [2004-06-01 17:22:22] fschaper at intux dot org Why not to call the destructors before the modules are shut down? I wrote a short patch for this and it works out fine (That does not mean however that it does not break something ,) ). http://www.intux.org/download/patches/patch_php_cvs_01_06_04.rar ------------------------------------------------------------------------ [2004-03-11 04:34:16] derick@php.net It's still not documented, leave it as an open doc bug. ------------------------------------------------------------------------ [2004-03-11 04:28:32] helly@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php The destructor is executed too late in the shutdown sequence. If you want a destructor to modify some $_SESSION then you need to manually refcount and free all references using unset() before the script terminates. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/27555 -- Edit this bug report at http://bugs.php.net/?id=27555&edit=1

« previous php.doc (#969361752) next »