[PHP-BUG] Bug #63462 [NEW]: Magic methods called twice for unset protected properties
From: ocramius at gmail dot com Operating system: Irrelevant PHP version: 5.4.8 Package: Scripting Engine problem Bug Type: Bug Bug description:Magic methods called twice for unset protected properties Description: When un-setting a private or protected property of an object, magic methods get called twice when that property is accessed. Test script: --- https://gist.github.com/4037010 (will provide PR with the test later) Expected result: Each of the magic methods presented in the test script should be called only once per checked property. Actual result: -- Each of the magic methods are called twice for private or protected properties that were unset. -- Edit bug report at https://bugs.php.net/bug.php?id=63462&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63462&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63462&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63462&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63462&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63462&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63462&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63462&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63462&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63462&r=support Expected behavior: https://bugs.php.net/fix.php?id=63462&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63462&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63462&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63462&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63462&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63462&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63462&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63462&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63462&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63462&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63462&r=mysqlcfg
Bug #63462 [Opn]: Magic methods called twice for unset protected properties
Edit report at https://bugs.php.net/bug.php?id=63462&edit=1 ID: 63462 User updated by:ocramius at gmail dot com Reported by:ocramius at gmail dot com Summary:Magic methods called twice for unset protected properties Status: Open Type: Bug Package:Scripting Engine problem Operating System: Irrelevant PHP Version:5.4.8 Block user comment: N Private report: N New Comment: I've added the failing test case as a PR at https://github.com/php/php-src/pull/229 Previous Comments: [2012-11-08 05:40:59] ocramius at gmail dot com Description: When un-setting a private or protected property of an object, magic methods get called twice when that property is accessed. Test script: --- https://gist.github.com/4037010 (will provide PR with the test later) Expected result: Each of the magic methods presented in the test script should be called only once per checked property. Actual result: -- Each of the magic methods are called twice for private or protected properties that were unset. -- Edit this bug report at https://bugs.php.net/bug.php?id=63462&edit=1
[PHP-BUG] Bug #63463 [NEW]: ReflectionProperty::setValue and ::getValue trigger magic methods
From: ocramius at gmail dot com Operating system: Irrelevant PHP version: 5.4.8 Package: Reflection related Bug Type: Bug Bug description:ReflectionProperty::setValue and ::getValue trigger magic methods Description: When unset properties are requested, ReflectionProperty::setValue and ReflectionProperty::getValue trigger __get and __set magic methods. Test script: --- https://gist.github.com/4037155 Expected result: The test script should report NULL for each of the requested values, and never call __set nor __get Actual result: -- __set and __get are called when ReflectionProperty tries to read or write to the requested properties. -- Edit bug report at https://bugs.php.net/bug.php?id=63463&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63463&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63463&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63463&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63463&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63463&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63463&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63463&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63463&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63463&r=support Expected behavior: https://bugs.php.net/fix.php?id=63463&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63463&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63463&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63463&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63463&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63463&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63463&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63463&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63463&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63463&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63463&r=mysqlcfg
Bug #63463 [Com]: ReflectionProperty::setValue and ::getValue trigger magic methods
Edit report at https://bugs.php.net/bug.php?id=63463&edit=1 ID: 63463 Comment by: ocramius at gmail dot com Reported by:ocramius at gmail dot com Summary:ReflectionProperty::setValue and ::getValue trigger magic methods Status: Open Type: Bug Package:Reflection related Operating System: Irrelevant PHP Version:5.4.8 Block user comment: N Private report: N New Comment: I've added the failing test case as a PR at https://github.com/php/php-src/pull/230 Previous Comments: [2012-11-08 06:15:03] ocramius at gmail dot com Description: When unset properties are requested, ReflectionProperty::setValue and ReflectionProperty::getValue trigger __get and __set magic methods. Test script: --- https://gist.github.com/4037155 Expected result: The test script should report NULL for each of the requested values, and never call __set nor __get Actual result: -- __set and __get are called when ReflectionProperty tries to read or write to the requested properties. -- Edit this bug report at https://bugs.php.net/bug.php?id=63463&edit=1
Bug #55731 [Com]: __get after __unset
Edit report at https://bugs.php.net/bug.php?id=55731&edit=1 ID: 55731 Comment by: ocramius at gmail dot com Reported by:421034509 at qq dot com Summary:__get after __unset Status: Not a bug Type: Bug Package:Unknown/Other Function Operating System: windows xp PHP Version:5.3.8 Block user comment: N Private report: N New Comment: I got pointed here after filing #63462 ( https://bugs.php.net/bug.php?id=63462 ). Shouldn't the `getter_guard` be disabled for "\0Example\0p1: (laurence's example) when already in the context of `__get` (and similar logic for all the other magic methods)? I have absolutely no understanding of PHP internals about this, but I wouldn't expect the magic getter to work again for the same property when we already know it was the requested one. This is actually a (quite problematic) bug for me since it denies any action on unset properties, which is a feature I need when working with proxies. If I understand this correctly, at https://github.com/php/php-src/blob/6ba376f552238de643a665d355fd5e59c40315b5/Zend/zend_object_handlers.c#L559-572 the guard is used. I don't understand why `guard->in_set` isn't checked the second time though. Does `zend_get_property_guard` retrieve a different item for different `property_info`? Previous Comments: [2011-09-22 03:36:35] 421034509 at qq dot com Thank you!I got it! [2011-09-22 01:28:25] larue...@php.net No, if the property is private, and the getter is called out of call entry(means access a private property out of scope), zend vm will return NULL, but zend_read_property will assume as a "public property name", since PHP is a flexible language. [2011-09-22 01:18:53] 421034509 at qq dot com When get_property_info successed in the Example class, if the private property is defined but be unsetted,zend vm return a property info with name "\0Example\0propertyname", but if the property is undefined(or defined but not be unsetted),zend vm return a property info with name "propertyname". Is that true? [2011-09-22 01:17:55] larue...@php.net because there is no '\0Example\0p3' in property_info of Example class entry [2011-09-21 16:51:52] hytest at gmail dot com If we add following code: echo $example->p3; It still just call __get once. Why it doesn't call it twice? ( one for "p3" and one for "\0example\0p3" ? ) In another word: what's the different between a property not defined and a unset private property? 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 https://bugs.php.net/bug.php?id=55731 -- Edit this bug report at https://bugs.php.net/bug.php?id=55731&edit=1
Bug #63463 [Fbk->Opn]: ReflectionProperty::setValue and ::getValue trigger magic methods
Edit report at https://bugs.php.net/bug.php?id=63463&edit=1 ID: 63463 User updated by:ocramius at gmail dot com Reported by:ocramius at gmail dot com Summary:ReflectionProperty::setValue and ::getValue trigger magic methods -Status: Feedback +Status: Open Type: Bug Package:Reflection related Operating System: Irrelevant PHP Version:5.4.8 Block user comment: N Private report: N New Comment: @stas let me put it into a more "practical" use case I currently have: I use reflection to populate instances of proxy objects that have "lazy" marked properties unset at instantiation time. This is good to achieve lazy loading of public properties, but any r/w access to the property itself via reflection triggers `__get` or `__set`. This makes it impossible to use reflection to populate the property. I worked around it by disabling `__get` in particular situations (see https://github.com/Ocramius/common/blob/DCOM-96/lib/Doctrine/Common/Reflection/RuntimePublicReflectionProperty.php), but at a terrible cost in performance terms and broken behaviour in rare cases. Back to the issue itself: I consider Reflection as my last resource to access and modify status of objects without affecting anything else within my environment. Having reflection trigger any logic during an assignment is an unwanted and dangerous behaviour in my opinion. Previous Comments: [2012-12-10 01:51:32] s...@php.net I'm not sure why you think this is what should be happening. When you unset properties, they are no longer set. And when you access unset properties, magic methods kick in. So where's the problem here? ---- [2012-11-08 06:22:43] ocramius at gmail dot com I've added the failing test case as a PR at https://github.com/php/php-src/pull/230 ---- [2012-11-08 06:15:03] ocramius at gmail dot com Description: When unset properties are requested, ReflectionProperty::setValue and ReflectionProperty::getValue trigger __get and __set magic methods. Test script: --- https://gist.github.com/4037155 Expected result: The test script should report NULL for each of the requested values, and never call __set nor __get Actual result: -- __set and __get are called when ReflectionProperty tries to read or write to the requested properties. -- Edit this bug report at https://bugs.php.net/bug.php?id=63463&edit=1
Bug #63463 [Nab]: ReflectionProperty::setValue and ::getValue trigger magic methods
Edit report at https://bugs.php.net/bug.php?id=63463&edit=1 ID: 63463 User updated by:ocramius at gmail dot com Reported by:ocramius at gmail dot com Summary:ReflectionProperty::setValue and ::getValue trigger magic methods Status: Not a bug Type: Bug Package:Reflection related Operating System: Irrelevant PHP Version:5.4.8 Block user comment: N Private report: N New Comment: Isn't reflection able to handle properties in a different way from how userland code acts? I wouldn't consider Reflection at the same level of other code, or at least I'm not aware of any way of achieving the same functionality without having access to internal APIs. I'm not denying the fact that this is probably a design issue and that it would require major refactoring to workaround it, but the fact that such effort is needed doesn't mean that this is not a bug. Want to mark it as improvement instead? Or as a documentation issue and therefore language limitation (with relative improvement issue)? Previous Comments: [2012-12-18 21:15:18] s...@php.net I am sorry, but I think your opinion is incorrect. Reflection works the same way and uses the same engine methods as other ways of accessing properties. Making Reflection work differently from the rest of the object model would require special exceptions in all object engine for Reflection and seems to make little sense to me in general. Reflection is just another way of doing the same thing as regular property access. I am sorry that your code does not work as you wanted it to, and you are welcome to propose ways to improve it, including participating in getters/setters discussion ongoing, but I do not think in this particular case reflection is doing something wrong. In any case, it is not a bug as the code is doing exactly as the intent of the code was for it to do. ---- [2012-12-10 02:04:46] ocramius at gmail dot com @stas let me put it into a more "practical" use case I currently have: I use reflection to populate instances of proxy objects that have "lazy" marked properties unset at instantiation time. This is good to achieve lazy loading of public properties, but any r/w access to the property itself via reflection triggers `__get` or `__set`. This makes it impossible to use reflection to populate the property. I worked around it by disabling `__get` in particular situations (see https://github.com/Ocramius/common/blob/DCOM-96/lib/Doctrine/Common/Reflection/RuntimePublicReflectionProperty.php), but at a terrible cost in performance terms and broken behaviour in rare cases. Back to the issue itself: I consider Reflection as my last resource to access and modify status of objects without affecting anything else within my environment. Having reflection trigger any logic during an assignment is an unwanted and dangerous behaviour in my opinion. [2012-12-10 01:51:32] s...@php.net I'm not sure why you think this is what should be happening. When you unset properties, they are no longer set. And when you access unset properties, magic methods kick in. So where's the problem here? ---------------- [2012-11-08 06:22:43] ocramius at gmail dot com I've added the failing test case as a PR at https://github.com/php/php-src/pull/230 ---------------- [2012-11-08 06:15:03] ocramius at gmail dot com Description: When unset properties are requested, ReflectionProperty::setValue and ReflectionProperty::getValue trigger __get and __set magic methods. Test script: --- https://gist.github.com/4037155 Expected result: The test script should report NULL for each of the requested values, and never call __set nor __get Actual result: -- __set and __get are called when ReflectionProperty tries to read or write to the requested properties. -- Edit this bug report at https://bugs.php.net/bug.php?id=63463&edit=1
