Edit report at https://bugs.php.net/bug.php?id=63463&edit=1
ID: 63463 Comment by: evan at digitalflophouse 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: It would seem to me that the ideal solution here would be for ReflectionProperty::setValue and ::getValue to support an optional parameter indicating whether magic methods should be triggered (the default) or not. Previous Comments: ------------------------------------------------------------------------ [2012-12-18 23:11:42] ocramius at gmail dot com 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)? ------------------------------------------------------------------------ [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 ------------------------------------------------------------------------ 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=63463 -- Edit this bug report at https://bugs.php.net/bug.php?id=63463&edit=1