#29070 [Opn->Csd]: __get/__set should allow recursive calls

From: Date: Wed, 01 Mar 2006 07:30:35 +0000
Subject: #29070 [Opn->Csd]: __get/__set should allow recursive calls
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-93784@lists.php.net to get a copy of this message
ID: 29070 Updated by: tony2001@php.net Reported By: csmoak at andrew dot cmu dot edu -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: All PHP Version: 5.0.0RC3 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: ------------------------------------------------------------------------ [2005-08-15 12:14:52] ilia at manual dot ru This is a really annoying issue. I actually was frustrated by it when the whole system was already ready 'on paper'. You can set a border of e.g 1000 calls to catch the infinite recursion, if you wish but one shouldn't catch programmer's hand - let him have the recursion if he wants to! The current behaviour is USELESS, while allowing recursive calls is HELPFUL. This seems quite a reason to fix that.. ------------------------------------------------------------------------ [2004-07-15 11:48:06] derick@php.net It's still a feature request. ------------------------------------------------------------------------ [2004-07-15 05:59:09] csmoak at andrew dot cmu dot edu This really should be taken care of. ------------------------------------------------------------------------ [2004-07-09 06:57:23] csmoak at andrew dot cmu dot edu Description: ------------ __get() and __set() are currently blocked from being implicitly called for a particular instance of an object when they are currently executing. However, this can cause code to behave differently if it is called from within __get()/__set() or if it is called without __get()/__set(). The following example uses good OOP methodology that tries to make use of __get() and __set(), but is hindered by it, instead. The problem lies in the use of the in_get and in_set member variables in the zend_object strcut to provide a blanket block to calling __get or __set recursively (when called implicitly). A possible solution would be to only prevent code directly in the __get() and __set() method bodies from implicitly calling __get() or __set(), but allowing it in any called code. Reproduce code: --------------- http://www.andrew.cmu.edu/user/csmoak/getset.phps Expected result: ---------------- correct behavior (without making use of __get/__set):<br> before set : default<br> after set : propertyValue<br> PropertyAccessClass Object ( [property:private] => propertyValue [defaultProperty:private] => default [changed:private] => 1 ) <br><br> incorrect behavior (making use of __get/__set):<br> before set : default<br> after set : propertyValue<br> PropertyAccessClass Object ( [property:private] => propertyValue [defaultProperty:private] => default [changed:private] => 1 ) Actual result: -------------- correct behavior (without making use of __get/__set):<br> before set : default<br> after set : propertyValue<br> PropertyAccessClass Object ( [property:private] => propertyValue [defaultProperty:private] => default [changed:private] => 1 ) <br><br> incorrect behavior (making use of __get/__set):<br> <br /> <b>Notice</b>: Undefined property: PropertyAccessClass::$PropertyChanged in <b>C:\ftproot\pnet\test2.php</b> on line <b>22</b><br /> <br /> <b>Notice</b>: Undefined property: PropertyAccessClass::$DefaultProperty in <b>C:\ftproot\pnet\test2.php</b> on line <b>33</b><br /> before set : <br> after set : propertyValue<br> PropertyAccessClass Object ( [property:private] => propertyValue [defaultProperty:private] => default [changed:private] => [PropertyChanged] => 1 ) ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=29070&edit=1

« previous php.bugs (#93784) next »