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? [EMAIL PROTECTED] 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] [EMAIL PROTECTED]

It's still not documented, leave it as an open doc bug.

------------------------------------------------------------------------

[2004-03-11 04:28:32] [EMAIL PROTECTED]

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

Reply via email to