|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #70508 Support ::function similar to ::class
Submitted: 2015-09-15 21:31 UTC Modified: 2016-03-26 21:46 UTC
Avg. Score:3.5 ± 0.5
Reproduced:1 of 2 (50.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: andreas at dqxtech dot net Assigned:
Status: Suspended Package: Scripting Engine problem
PHP Version: 7.0.0RC2 OS: Linux
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2015-09-15 21:31 UTC] andreas at dqxtech dot net
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:

Actual result:
Fatal error: syntax error, unexpected T_DOUBLE_COLON


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2015-09-15 21:34 UTC] 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:36 UTC]
-Package: PHP Language Specification +Package: Scripting Engine problem
 [2015-09-15 21:50 UTC]
See also (withdrawn) which suggests
  $callback = &\MyVendor\MyLibrary\MyClass::foo;

There's the discussion for it too
where "::function" also makes an appearance, but both solutions have problems.
 [2015-09-15 22:29 UTC] andreas at dqxtech dot net

> See also (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
> 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-12-19 04:23 UTC]
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.
 [2015-12-19 04:23 UTC]
Or, well, PHP does not have an autoloader for functions just now. But if it did, this would be a problem. And either way we can't do it at compile-time.
 [2016-03-26 21:46 UTC]
-Status: Open +Status: Suspended
 [2016-03-26 21:46 UTC]
For this kind of change, an RFC is required.

Please see:
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Fri Aug 23 10:01:26 2019 UTC