Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99228
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.41 as permitted sender)
Date: Mon, 29 May 2017 12:01:40 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <CA+kxMuT+MBX1e71y9i3Kfn0cCAWG8+iPW=TY1VA532q6Jkg=LA@mail.gmail.com>
References: <CA+kxMuT+MBX1e71y9i3Kfn0cCAWG8+iPW=TY1VA532q6Jkg=LA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: internals@lists.php.net
Message-ID: <4CFF3E6E-5B9B-49CE-9603-33170CD63421@gmail.com>
Subject: Re: [PHP-DEV] [RFC][Discussion] Consistent callables
From: rowan.collins@gmail.com (Rowan Collins)

On 28 May 2017 22:23:30 BST, Dan Ackroyd <danack@basereality=2Ecom> wrote:
>Hi,
>
>I'd like to introduce an RFC to cleanup the behaviour of callables and
>related functions in PHP=2E
>
>https://wiki=2Ephp=2Enet/rfc/consistent_callables

Hi Dan,

I like the principle behind this RFC, so thanks for tackling it=2E A few c=
omments came to mind from a first read through:

In your strict definition of a callable, you mention "a string at index 0 =
which is a valid class name"; this should probably say "a fully qualified c=
lass name", i=2Ee=2E Foo:: class not 'Foo'=2E This would fit with your prop=
osal to remove support for 'self' and 'static', as the meaning of 'Foo' dep=
ends on the current namespace and aliases=2E

Regarding is_callable, I appreciate you want to keep the parameter list sh=
ort, but I think replacing an existing parameter without any version where =
it's removed completely could lead to some very confusing bugs=2E IMO, when=
 BC breaks are necessary, they should be big and obvious so people spot and=
 fix them=2E

Finally, I notice you target a few deprecations at "7=2Elast"; the problem=
 with that is that we might not know when we release that version that it w=
ill be the last=2E It wasn't decided until nearly a year after 5=2E6 was re=
leased that there wouldn't be a 5=2E7, and the idea of creating a 5=2E7 con=
taining only deprecations was ruled out=2E Suggestions to plot a roadmap of=
 future releases have so far but gained traction, so it's likely that 8=2E0=
 will be a similar scenario=2E

Regards,

--=20
Rowan Collins
[IMSoP]