Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114541
MIME-Version: 1.0
References: <CAF+90c_iYjsDWoqPaDtavVgj2WFdpiuBmGeQZFAqokVoVZTxoA@mail.gmail.com>
 <CALfTnfXDTvrtA9-hN+UH+qs3iS9q34jseunBD7YumGkonrSwXA@mail.gmail.com>
In-Reply-To: <CALfTnfXDTvrtA9-hN+UH+qs3iS9q34jseunBD7YumGkonrSwXA@mail.gmail.com>
Date: Thu, 20 May 2021 13:37:02 -0400
Message-ID: <CAKuGYLQzCS4YE7gLtjs02mXRPNPFUgJaPiMWY+bjkymx-2AAaw@mail.gmail.com>
To: =?UTF-8?Q?Ond=C5=99ej_Mirtes?= <ondrej@mirtes.cz>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c2cbec05c2c66456"
Subject: Re: [PHP-DEV] [RFC] First-class callable syntax
From: matthewmatthew@gmail.com (Matthew Brown)

--000000000000c2cbec05c2c66456
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 20 May 2021 at 10:17, Ond=C5=99ej Mirtes <ondrej@mirtes.cz> wrote:

> Hi, I=E2=80=99m confused by the syntax, when I read it, I think to myself=
 =E2=80=9CI know
> this, this is just a method call=E2=80=A6 oh wait, it=E2=80=99s actually =
a callable=E2=80=9D. It
> really makes my head hurt.
>

I agree with the first point =E2=80=94 slightly confusing initially, but I =
can see
myself get used to it. I suggested strlen(=3D>) as an alternative, not sure
if that would cause parsing difficulties.


> Also, static analysers already have to reason about current code, so
> PHPStan (and Psalm probably too) already supports referencing to callable=
s
> as strings (global functions) and arrays (methods):
>
> $name =3D 'date';
> $name(1); // Parameter #1 $format of callable 'date' expects string, int
> given.
>

I disagree here: while Psalm can understand what's going on in the above
code, callables are definitely (in my opinion) the most hairy part of PHP's
type system.

The RFC gives an example of something not caught by either PHPStan or Psalm=
:

https://psalm.dev/r/21217fdfb4
https://phpstan.org/r/6cc8cdc2-ecc6-403d-887d-0f12f4813b75

Discouraging this particular formulation would make affected codebases safe
from this particular error.

Best wishes,

Matt

--000000000000c2cbec05c2c66456--