|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2015-09-15 21:34 UTC] andreas at dqxtech dot net
[2015-09-15 21:36 UTC] stas@php.net
-Package: PHP Language Specification
+Package: Scripting Engine problem
[2015-09-15 21:50 UTC] requinix@php.net
[2015-09-15 22:29 UTC] andreas at dqxtech dot net
[2015-12-19 04:23 UTC] ajf@php.net
[2015-12-19 04:23 UTC] ajf@php.net
[2016-03-26 21:46 UTC] krakjoe@php.net
-Status: Open
+Status: Suspended
[2016-03-26 21:46 UTC] krakjoe@php.net
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Sat Nov 08 04:00:01 2025 UTC |
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