Req #50029 [Com]: Weird invoke issue on class as property

Edit report at https://bugs.php.net/bug.php?id=50029&edit=1 ID: 50029 Comment by: programmierung at pfink dot de Reported by: marc dot gray at gmail dot com Summary: Weird invoke issue on class as property Status: Analyzed Type: Feature/Change Request Package: Class/Object related Operating System: Ubuntu 9.04 PHP Version: 5.3.0 Block user comment: N Private report: N New Comment: The worst thing on this bug is that is_callable() returns true in this case even though it's not callable: The lines if(is_callable($this->objectWithInvokeMethod)) return $this->objectWithInvokeMethod(0); produce the fatal error Fatal error: Call to undefined method MyClass::objectWithInvokeMethod() Previous Comments: ------------------------------------------------------------------------ [2011-12-06 16:34:31] karsten at typo3 dot org I would go for simple rules to solve this. When having a class and calling $this->prop() PHP should * use __invoke on $this->prop if there is no method prop() in the class * if there is an actual method, the method takes precedence In the latter one can still use $this->prop->__invoke(), but should probably rather clean up the code. :) ------------------------------------------------------------------------ [2011-08-24 18:49:06] marc dot gray at gmail dot com I've been thinking about this since the same issue appears to exist with assigning a closure to a static variable too (tested in 5.3.5, 5.3.8 & 5.4alpha3. //---------------------------------- // Create a very basic static class class closureProperty { static public $myClosure; } // Assign a closure to a class property closureProperty::$myClosure = function() { echo('Hi'); }; // Fatal error: Function name must be a string closureProperty::$myClosure(); // Works as expected $safeCopy = closureProperty::$myClosure; $safeCopy(); //---------------------------------- I can understand why it happens with dynamic properties, apparently you can have a variable and function named identically? I admit I've never tried. I would propose making identically named variables and functions as deprecated (does anyone who's any good actually do that? Talk about poor readability...) and implement a collision warning in the mean time. I would also suggest this makes less sense in a static case (due to $ variable prefix) than it did in a dynamic case, and should be changed. If nothing else, some discussion on the matter would be lovely. Thoughts? ------------------------------------------------------------------------ [2011-02-07 22:36:54] dhaarbrink at gmail dot com @bkarwin: The control would be passed to __call(), since there is no way to disambiguate. __call() would then be responsible for deciding what to do. I have to agree with Matthew, it's a huge WTF. It just doesn't work as it should (that's beyond what is expected). ------------------------------------------------------------------------ [2010-04-07 20:22:38] bkarwin@php.net How would Matthew's suggestion work if a magic __call() method is present? class b { private $x; public function __call($method, $args) { echo "Called\n"; } function __construct() { $this->x = new a(); $this->x(); } } Should this execute $this->__call("x") and output "Called" or should it execute $this->x->__invoke() and output "Invoked"? ------------------------------------------------------------------------ [2010-04-07 14:52:19] ballouc at gmail dot com I'm in agreement with the Matt's last suggestion. I believe that errors should only be raised in the event of a collision. The current implementation of the __invoke method, IMO, would not perform as a third party developer would have anticipated. My personal choice would be to throw an E_WARNING for collisions as I have seen ~E_NOTICE far too often. Personally, I believe that an __invoke collision occurring would be more indicative of a developer error than intentional. If this is not the case, and you find many people readily anticipate having both foo() and __invoke called in succession, this would need to be discussed further as that is also a viable option. ------------------------------------------------------------------------ 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=50029 -- Edit this bug report at https://bugs.php.net/bug.php?id=50029&edit=1