From: cw264701 at ohiou dot edu Operating system: Ubuntu Linux PHP version: 5.2.0 PHP Bug Type: Class/Object related Bug description: PHP assumes that an object will not be used after serialize() is called on it
Description: ------------ PHP assumes that I will not use an object after serializing it. This shouldn't cause problems if my object's class does not define a __sleep() function, but if it does, and that __sleep() function modifies the object, then I can't reliably use that object until it is recreated using unserialize(). There is no mention of this in the documentation for the serialize() function, or anywhere else that I saw. More importantly, if PHP expects me to *not* use an object after calling serialize() on it, then PHP should produce an error message if I *do* try to use that object before unserialization. This is one of several problems (not all necessarily "bugs", but shaky designs), that I've come across recently, which greatly reduces the ability for PHP applications to take advantage of *transparency*. I.e., I should not have to care how a class is implemented (for instance, whether or not it uses the magic __sleep() function) to make use of it. I recently adopted the ezpdo (http://ezpdo.net/) ORM tool. It has probably hurt my productivity more than it has helped because it makes use of such leaky abstractions. Some of these may be the fault of that tool, but many flaws like this seem to be more general PHP problems. (Sorry for the rant, but I think issues like this are pretty important, and the reason I very often become frustrated with PHP.) Reproduce code: --------------- <?php class MultiplicationTable { public $size; public $table; public function MultiplicationTable( $size ) { $this->size = $size; for( $a = 1; $a <= $size; ++$a ) { for( $b = 1; $b <= $size; ++$b ) { $this->table[$a][$b] = $a * $b; } } } public function __sleep() { $this->table = null; return( array("size") ); } public function __wakeup() { $this->MultiplicationTable($this->size); } } $mt = new MultiplicationTable(4); echo $mt->size . ", " . $mt->table[4][4] . "\n"; $serialized_mt = serialize($mt); echo $mt->size . ", " . $mt->table[4][4] . "\n"; $unserialized_mt = unserialize($serialized_mt); echo $unserialized_mt->size . ", " . $unserialized_mt->table[4][4] . "\n"; ?> Expected result: ---------------- Well, ideally the object would still "work" after creating a serialize()'d version of it, but I think making that work would require significant changes to PHP's whole serialization model (or perhaps you could just have __wakeup() be called right after serialization; perhaps only if the object is accessed again). But, the more realistic solution would probably result in some kind of error message when I try to access my $mt object after calling serialize() on it. Actual result: -------------- 4, 16 4, 4, 16 -- Edit bug report at http://bugs.php.net/?id=39384&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39384&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39384&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39384&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39384&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39384&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39384&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=39384&r=needscript Try newer version: http://bugs.php.net/fix.php?id=39384&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39384&r=support Expected behavior: http://bugs.php.net/fix.php?id=39384&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39384&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39384&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39384&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39384&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39384&r=dst IIS Stability: http://bugs.php.net/fix.php?id=39384&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39384&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39384&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39384&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=39384&r=mysqlcfg
