Objects can in fact be stored in sessions. They are serialized for storage, the __sleep() and __wakeup() magic methods have been created to add functionality to the process.

Clarification regarding resources could be added to the current note on references to make things more clear.

to clarify further. 

CSD can be obtained, rather than CDS through the use of session_write_close().


If you'd like to argue for better documentation on shutdown order, or the fact that both the destructor and _sleep() are called when the script ends, that might be fair. But sessions can indeed store objects. 

note that X is actually destroyed, You've stored a serialized copy inside _SESSION, but there's that copy outside session as well, it is destroyed when the script ends.

[Please don't take bug reports lightly]

> Objects can in fact be stored in sessions.

No, they can't. See the php demo attached to this ticket.
IF you want to make php objects finalizable, you must introduce a new api, similar to 
Scheme's or Java's weak refs.

> They are serialized fo storage, the __sleep() and __wakeup() magic methods have 
bee

_sleep() is useless as it is called long after the objects have been nuked.

It's a chicken/egg problem. PHP must call _destruct() before it can call the session 
save handler. Therefore the handler cannot do much with the destroyed objects 
anymore.

> CSD can be obtained, rather than CDS through the use o session_write_close

A PHP library needs a reliable PHP behaviour. The library cannot force users to use 
or not use session_write_close() to properly write a session.

When __destroy() is called before __sleep(). the library has no other choice than to 
throw an exception telling the user that the object has already been destroyed by 
php. As a result users of the library report a bug to the library author.

I am trying to avoid these bug reports.

PHP can store objects in sessions. 
http://example.preinheimer.com/sessobj.php

The shutdown order (destruction before serialization) is likely faulty. Please file a bug against the language for that issue.

Actually, it a choice we have to make: first destroy objects or first terminate sessions.

Currently, we first call __destruct on objects, then terminate sessions.

This has the advantage of allowing objects destroyed at shutdown to still be able to manage session data.

The only drawback is that __sleep() gets called after __destruct which you discovered here. So maybe we should add a notice to __sleep's documentation.

I think the problem is that PHP currently does not support session objects which in turn manage external resources or implement __sleep()/__destruct() for other reasons. 

This problem could be fixed by introducing a "Finalizable" tagging interface. Objects implementing this interface will not be destroyed before rshutdown, but added to a internal "finalizable_list". This list is then traversed by the session module to call __sleep() on each object in the list. After rshutdown the gc will examine the finalizable_list again and destruct all objects in the list.

That means: Objects implementing the "Finalizable" interface will receive __sleep() before __destruct(), for all other objects the behaviour stays the same.

I think this should be easy to implement and won't break existing applications or libraries.

I will open a new ticket for this.

Thank you very much!

Already documented at http://www.php.net/manual/en/intro.session.php: "Some types of data can not be serialized thus stored in sessions. It includes resource variables"