Req #70508 [Com]: Support ::function similar to ::class

Edit report at https://bugs.php.net/bug.php?id=70508&edit=1 ID: 70508 Comment by: ajf@php.net Reported by: andreas at dqxtech dot net Summary: Support ::function similar to ::class Status: Open Type: Feature/Change Request Package: Scripting Engine problem Operating System: Linux PHP Version: 7.0.0RC2 Block user comment: N Private report: N New Comment: The problem with functions is that in a namespace, if you do, say, foo(), PHP can't know whether that's \foo() or \someNamespace\foo() without running the autoloader. Previous Comments: ------------------------------------------------------------------------ [2015-09-15 22:29:57] andreas at dqxtech dot net Well.. > See also https://wiki.php.net/rfc/function_referencing > (withdrawn) which suggests > $callback = &\MyVendor\MyLibrary\MyClass::foo; This is different in that it is meant to return a reference, whereas ::function would just return a string. I am not convinced of the reference stuff, but I strings are nice and plain and simple. > There's the discussion for it too > http://marc.info/?t=140710275400001&r=2&w=2 > where "::function" also makes an appearance, but both solutions have problems. I read the issues some people raised for ::function, but I don't agree. First, I don't know if the discussion meant ::function to return a reference or a string. I am very much advocating it to return a string, so it is consistent with ::class, and also has a simpler behavior. The supposed ambiguity of AmIAFunctionOrAClass::function is not really a problem. Right now, ::class does not trigger autoloading. Therefore, NonExistingClass::class will just return the class name, with no complaining. Even existingFunction::class, for an existing function, will return "existingFunction" as if it was a class. Likewise, ExistingClass::function should simply return "ExistingClass" as if it was a function. It should simply not care. Otherwise, the mechanic behavior would depend on whether a class was already autoloaded or not. This would suck. In fact ::class can already be abused as a funny alternative to string constants :) ------------------------------------------------------------------------ [2015-09-15 21:50:16] requinix@php.net See also https://wiki.php.net/rfc/function_referencing (withdrawn) which suggests $callback = &\MyVendor\MyLibrary\MyClass::foo; There's the discussion for it too http://marc.info/?t=140710275400001&r=2&w=2 where "::function" also makes an appearance, but both solutions have problems. ------------------------------------------------------------------------ [2015-09-15 21:34:55] andreas at dqxtech dot net So far my workaround is: /* @see C::foo() */ $callback = 'C::foo'; This allows the IDE to "Find usages". But I need to manually check that the @see and the string are identical. ------------------------------------------------------------------------ [2015-09-15 21:31:33] andreas at dqxtech dot net Description: ------------ Classes like ReflectionFunction, ReflectionMethod, or built-in functions like array_filter() accept functions identified as strings. This often leads to code like this, which is hard to analyse by the IDE: $callback = '\MyVendor\MyLibraray\MyClass::foo'; For classes, I already use the ::class language construct to make this understandable to the IDE, and allow things like "Find usages", or to let the IDE tell me that the class does not exist. I suggest to introduce a similar construct for functions and methods, ::function. Test script: --------------- class C { function fooMethod() {} } function fooFunction() {} print C::fooMethod::function . "\n"; print fooFunction::function . "\n"; Expected result: ---------------- C::fooMethod fooFunction Actual result: -------------- Fatal error: syntax error, unexpected T_DOUBLE_COLON ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=70508&edit=1