ID: 29070 Comment by: ilia at manual dot ru Reported By: csmoak at andrew dot cmu dot edu Status: Open Bug Type: Feature/Change Request Operating System: All PHP Version: 5.0.0RC3 New Comment:
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.. Previous Comments: ------------------------------------------------------------------------ [2004-07-15 11:48:06] [EMAIL PROTECTED] 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
