Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93343
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.47 as permitted sender)
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (1.0)
In-Reply-To: <CA+kxMuQxSj2enCXxZ50qgR-ehrvLEGJFjoc+xcyosN=6zowtjQ@mail.gmail.com>
Date: Sun, 15 May 2016 21:20:42 +0300
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <44BB42FB-4991-4531-827D-AF6A97B2675B@gmail.com>
References: <CA+kxMuQxSj2enCXxZ50qgR-ehrvLEGJFjoc+xcyosN=6zowtjQ@mail.gmail.com>
To: Dan Ackroyd <danack@basereality.com>
Subject: Re: [PHP-DEV] [RFC][VOTE] Closure from callable
From: inefedor@gmail.com (Nikita Nefedov)


> On 15 May 2016, at 20:29, Dan Ackroyd <danack@basereality.com> wrote:
>=20
> Hello,
>=20
> I've opened the voting for the Closure from callable RFC -
> https://wiki.php.net/rfc/closurefromcallable
>=20
> 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:
>=20
> callable(someFunctionName)
> callable($this->method)
>=20
> 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:
>=20
> class Foo {
>   public $method;
>   public function method() { }
> }
>=20
> 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 fiel=
d it probably already contains a closure (or, well, if you need to make a cl=
osure from arbitrary callable we could have a Closure::fromCallable named ct=
r). Instead of making a function 'callable()', we could make a language cons=
truct:

   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 refac=
toring in IDEs).

I see merging symbol tables as a pretty big of a deal for too much people, t=
his thing alone could easily create another case of Python 3 syndrome.