Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99223
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain koalephant.com designates 206.123.115.54 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
In-Reply-To: <CA+kxMuT+MBX1e71y9i3Kfn0cCAWG8+iPW=TY1VA532q6Jkg=LA@mail.gmail.com>
Date: Mon, 29 May 2017 16:28:54 +0700
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <10E6F2E5-45E6-4D20-9DDD-F8C1632A8CA4@koalephant.com>
References: <CA+kxMuT+MBX1e71y9i3Kfn0cCAWG8+iPW=TY1VA532q6Jkg=LA@mail.gmail.com>
To: Dan Ackroyd <danack@basereality.com>
Subject: Re: [PHP-DEV] [RFC][Discussion] Consistent callables
From: php-lists@koalephant.com (Stephen Reay)

> On 29 May 2017, at 04:23, Dan Ackroyd <danack@basereality.com> wrote:
>=20
> Hi,
>=20
> I'd like to introduce an RFC to cleanup the behaviour of callables and
> related functions in PHP.
>=20
> https://wiki.php.net/rfc/consistent_callables
>=20
> Note, this RFC targets PHP 8, with soft deprecations in PHP 7.3 and
> deprecation notices in 7.last. This means there is a lot of time for
> reading and thinking about the RFC.
>=20
> One piece of feedback I've had from informal discussions is that the
> BC break for one part is too big even for a major release number. I'd
> like to get other people's opinion on the RFC before possibly
> modifying it.
>=20
> Additionally modifying the signature of is_callable() might not be the
> best path. Again, looking forward to getting the opinion of other
> people.
>=20
> cheers
> Dan
> Ack
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20

Hi Dan,


While there *is* a difference, your resulting comments are reversed for =
the "call_user_func different from is_callable=E2=80=9D section. The =
call_user_func invocation works properly, the direct invocation does =
not.


A *lot* of the things you=E2=80=99re highlighting as =E2=80=9Cerrors=E2=80=
=9D or =E2=80=9Cis_callable lied to us=E2=80=9D are neither - they=E2=80=99=
re just a consequence of scope, and I think the wording should be =
changed, because =E2=80=9Cit lied=E2=80=9D has very different meaning to =
=E2=80=9Cit=E2=80=99s response is not necessary applicable in a =
different scope=E2=80=9D. If an astronaut on the moon says he weighs =
11.5kg, but you are looking at his medical report on Earth and it says =
he weighs 69kg, would you call him a liar?=20


Regarding the big change you suggest, making protected/private methods =
return false unless a new third parameter is true in is_callable():

I think you need to make your intention a *lot* clearer under the =
"Private and protected functions no longer report as callable for =
is_callable=E2=80=9D section. You make no mention of it being user =
controlled, simply =E2=80=9Cthis will not work any more=E2=80=9D, until =
the next section.

As for the actual change: I think for the sake of BC, and frankly logic, =
it would make *more* sense, to reverse your flag, so the default =
respects current behaviour, *but* it gives people who rely on =
is_callable() from another scope the ability to make sure they only get =
universally-callable values.

Lastly - you mention the need to use Reflection to create closures, but =
Closure::fromCallable exists, so perhaps you drafted this before that =
passed, and haven=E2=80=99t updated that part?


Cheers,

Stephen