Re: [RFC][VOTE] Closure from callable
| From: | Nikita Nefedov | Date: | Sun, 15 May 2016 18:20:42 +0000 |
| Subject: | Re: [RFC][VOTE] Closure from callable | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-93343@lists.php.net to get a copy of this message | ||
> On 15 May 2016, at 20:29, Dan Ackroyd <danack@basereality.com> wrote:
>
> Hello,
>
> I've opened the voting for the Closure from callable RFC -
> https://wiki.php.net/rfc/closurefromcallable
>
> Just to note, some people I've spoken to have expressed a desire to
> have a more powerful syntax where 'bare' function names are used,
> like:
>
> callable(someFunctionName)
> callable($this->method)
>
> I fully agree with those people, however I can't see anyway to do that
> before PHP 8. It would almost certainly need some clean up of the
> allowed syntax to disambiguate what
$this->method means for:
>
> class Foo {
> public $method;
> public function method() { }
> }
>
> Leaving that top-level function name available for future versions,
> where we might be able to support it properly, is one of the reasons
> to use the more verbose function name.
Hey Dan,
why would you need to support a $this->fieldName case though? If it's a field it probably
already contains a closure (or, well, if you need to make a closure from arbitrary callable we could
have a Closure::fromCallable named ctr). Instead of making a function 'callable()', we
could make a language construct:
expr:
...
| T_CALLABLE '(' callable_expr ')'
callable_expr:
'$this->' function_name
| class_name '::' function_name
| function_name
This would have an advantage of being statically checked (hence easier refactoring in IDEs).
I see merging symbol tables as a pretty big of a deal for too much people, this thing alone could
easily create another case of Python 3 syndrome.