Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117238
MIME-Version: 1.0
References: <CAFv4g+Efz-V5V1uUedXpusNw6z-on=TT3kdWgC66SptSd8kB4g@mail.gmail.com>
 <CAFv4g+GDsq=w7qtSOVptEBiTTDZk2aeFCVGThVBR=0-xk=0oAA@mail.gmail.com>
 <983552d8-11f1-b5bc-fb82-148347982fda@gmx.de> <5494eaa7-2fa6-8364-9683-a2c8c9789d81@gmail.com>
 <CAC5V6gjianVuPo654_-mETYxsu0-eSo++Ez1yy81MNEcfwFq1Q@mail.gmail.com>
 <69642616-72b7-44fe-97a7-27ae03bc8fce@www.fastmail.com> <CAFv4g+F0HOgCgeUyiG06qhxQnWbVCN2aaP=a2CJT9tkbMP7kLg@mail.gmail.com>
 <7fbed755-42e2-d023-285f-39863a97f297@gmx.de> <3665C848-B4C3-4528-AEFA-02C868748AA8@cschneid.com>
 <0b5bc29d-3814-0e1d-b94a-47790019c778@gmx.de> <CAFv4g+HPm+edmgnPAGwBk=4EJxj2can--iWfgtMasrYHk6pLww@mail.gmail.com>
 <4bff3f23-a3ec-4416-f44e-1f4f5d7e0caa@gmail.com> <CAFv4g+E159xoR4hxtsay-FamCSrJN+DmodvjzYGHcd1pQFsX+Q@mail.gmail.com>
 <2d06bc12-7d7e-4a88-b823-de64642381e6@www.fastmail.com> <CAAwdEzDqkLb=LDNH=1TJHkuHq31DsWMaTZ-TbRuU0wxRLRT43A@mail.gmail.com>
In-Reply-To: <CAAwdEzDqkLb=LDNH=1TJHkuHq31DsWMaTZ-TbRuU0wxRLRT43A@mail.gmail.com>
Date: Thu, 3 Mar 2022 10:56:28 +0000
Message-ID: <CAFv4g+GjApbFs6aWz9zv8cPMLWFMLM0FOA=-Dc6VSd=LOgSKLA@mail.gmail.com>
To: =?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?= <drealecs@gmail.com>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b0962c05d94e40a6"
Subject: Re: [PHP-DEV] Allowing NULL for some internal functions
From: craig@craigfrancis.co.uk (Craig Francis)

--000000000000b0962c05d94e40a6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2 Mar 2022 at 21:42, Alexandru P=C4=83tr=C4=83nescu <drealecs@gmail=
.com>
wrote:

> What bothers me a bit is why should strlen(false) be a valid method call
> but strlen(null) not so much. I think this is the inconsistency that shou=
ld
> be fixed so the language would be easier to work with.
>


Hi Alexandru,

I typically spend an hour carefully thinking about each email I send, both
on and off list. I read and re-read what each person said, I try to
understand why they are saying it, my replies / suggestions are me trying
to find the best solution that will work for as many people as possible,
and the consequences they would have. I do not consider my coding style to
be only one, and I would never simply force someone to work in a different
way, in the same way that I won't force a CSP scrpt-src that blocked
'unsafe-inline' on everyone no matter how many XSS vulnerabilities it would
solve (I highlight provable problems, I make suggestions on how to fix, and
I'm open to alternative ideas).

With this RFC, I made my original suggestion, which was to alter some
functions so they could continue to accept NULL. I was wrong with that
approach (first I suggested doing this silently, which Larry correctly
pointed out was too messy; then I considered Larry's idea of updating
function signatures, but there are too many, and would reduce some useful
checks for those using `strict_types`).

The solution I have been proposing for the last week or so is based on
making PHP work with the well documented and understood coercion behaviour
for null, in a way that keeps with the spirit of the original RFC, and is
how many PHP scripts work today (noting that your typical PHP developer
does not dare enter the Internals mailing list).

I respect your idea, but what you are suggesting is very messy, it seems to
randomly deprecate and remove some type coercions, but that is just going
to confuse developers, and make upgrading harder to 9.0 even harder than
what is currently planned (see Python 2 to 3 as a classic example). I know
some people here fantasise of forcing everyone to use `strict_types`, and
making everyone use static analysis tools, but we are a long way off from
that happening today... what we can do - make it easy to move to
`strict_types` (ideally with good tooling), to sell that approach with the
positives it brings, while also keeping non-`strict_types` working as
expected so people continue to upgrade.

Craig

--000000000000b0962c05d94e40a6--