Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94171
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.50 as permitted sender)
Content-Type: text/plain; charset=koi8-r; format=flowed; delsp=yes
To: "internals@lists.php.net" <internals@lists.php.net>
Date: Tue, 21 Jun 2016 12:44:29 +0300
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-ID: <op.yjeiofyac9evq2@nikita-pc>
User-Agent: Opera Mail/12.17 (Win32)
Subject: Statically verifiable callables
From: inefedor@gmail.com ("Nikita Nefedov")

Morning internals,

I would like to gather some reactions on the proposal to add
a 'statically verifiable callable as a closure language construct'.

That would be functionally similar to the recently added
Closure::fromCallable() with the exception being statically
verified by IDEs or precompilers/linters/code inspection tools.

Right now it is absolutely context-dependent guess whether
`[$obj, 'foo']` is a reference to a method `foo` of `$obj`
or something completely different. This makes code analysis and
refactoring very hard when it comes to using methods/functions
as callables passed somewhere.

What I'm proposing is to add a language construct, the usage of
which would look similar to this:

     function bar() {}
     class Foo { function dyn(){} static function stat(){} }

     callable(Foo::stat);

     callable((new Foo)->dyn);

     callable(bar);

callable() construct would return a Closure instance, just like
Closure::fromCallable() does but without the overhead of parsing
the array and with all function/class identifiers being T_STRINGs
rather than string literals.

The main advantage for me personally will be IDEs being able to
implement refactoring and code highlighting (=> more readable)
features on top of this (e.g. rename method can also rename all
accesses to this method but not when it's a string literal).

I'm aware that people might not like the fact that with this
syntax method access looks completely the same to the
field access and can be misleading for novices or can harm
readability of the code. If someone has better ideas we can
all share them here.

The patch should be pretty simple, here for example are the
parser changes I made to make sure this syntax is possible:

https://gist.github.com/nikita2206/bf419c8c23479bbf826c31cffe16a749