Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117523
MIME-Version: 1.0
References: <CAFv4g+Ej4JbM9SzQ0iU-d8C4T+2XNo=8jnJ1uwfQ=skZZXx9Tg@mail.gmail.com>
 <CAFPFaML-dia9d7qhpqsVjaQ1vruF+eODXYtieow8BhZ69HL4YQ@mail.gmail.com> <CAFv4g+GQbFVtNvBQrrCYJpNEw-wpzd1QqTFpyyppFQjuMs8dSg@mail.gmail.com>
In-Reply-To: <CAFv4g+GQbFVtNvBQrrCYJpNEw-wpzd1QqTFpyyppFQjuMs8dSg@mail.gmail.com>
Date: Wed, 13 Apr 2022 15:15:14 +0100
Message-ID: <CAFPFaMLx3pA7SS2aefcgG88ucqZAUK_F=eRpMn=3XL1_JVCsxw@mail.gmail.com>
To: Craig Francis <craig@craigfrancis.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000eecf005dc89cf00"
Subject: Re: [PHP-DEV] NULL Coercion Consistency
From: george.banyard@gmail.com ("G. P. B.")

--0000000000000eecf005dc89cf00
Content-Type: text/plain; charset="UTF-8"

On Mon, 11 Apr 2022 at 19:22, Craig Francis <craig@craigfrancis.co.uk>
wrote:

> On Mon, 11 Apr 2022 at 16:14, G. P. B. <george.banyard@gmail.com> wrote:
>
>> But the implementation caused a Type Error when coercing NULL for
>>> everyone (even when not using *strict_types=1*), this seems more of an
>>> over-sight
>>>
>> is utterly wrong and was a conscious design choice based on the widely
>> accepted view that nullable by default like Java is a mistake and defeats
>> the purpose.
>>
>
>
> Bit hash... anyway, I've replaced that paragraph (it wasn't clear enough),
> I just wanted to note how developers not using `strict_types=1` would see
> it as an over-sight that coercion works for string/int/float/bool but not
> null (despite what the documentation says), and how it's introduced a type
> check (that they didn't ask for).
>
> I assume you're using `strict_types=1`, and will be unaffected by this, so
> with all due respect, I'm not considering how you view or use NULL, nor do
> I care what Java does, I'm simply focused on how most developers use NULL
> in PHP.
>

If I indeed exclusively used strict_types I wouldn't care, but I don't
because IMHO strict_types were a mistake and are harmful and induce some
self inflicted problems.
I've spent a large amount of time making coercive typing mode more sensible
and aligning the behaviour as close to reasonably possible with
strict_types so that the possibility of dropping strict_types all together
wouldn't be outrageous.
I've written about this elsewhere and on this list already but main points
are located here: https://github.com/Girgias/unify-typing-modes-rfc

Userland scalar types, however they would have been introduced, did not
include coercion from NULL for *very* good reasons.
Wanting to change this behaviour needs more justification than a paragraph
in docs, as the docs should reflect the reality of the implementation.

The second aspect is the general consensus that internals and userland
should behave identically.
Which is why the deprecation is here in the first place, to align internal
behaviour with the accepted *better* design choice of userland.

Your RFC is going against these two pillars.
Moreover, the fact that we are deprecating this and not just changing the
behaviour from one version to another is that we do recognize PHP
developers use NULL in this way, and we are giving them advance notice of
the change.
Also a deprecation notice should, IMHO, never be promoted to an exception.
This is maybe something we need to get better at teaching end users so that
they don't pressure library maintainers (or themselves) to fix all of them
when they still have a couple of years.
Be that either on the php.net docs or elsewhere, to teach end users to
either not do this, or at least exclude the vendor directory from their
error handler.

However, and I cannot stress this enough, we cannot just stop using this
tool available to us to steer the language into being better.
Because then the other two choices are doing hard breaks with no notice in
a major version, or not breaking anything. Both things which are
unreasonable to expect.
There are behaviours of PHP that will probably never be "fixable", but this
should not prevent us from improving the aspects we can.
And if we only focused on how developers use PHP we would still have
register globals, magic quotes, etc.

Clearly it seems you won't listen to why these changes were made and want
to reverse course, therefore good luck convincing enough people to accept
such an RFC.

I think I've said all there is to say and won't interact further with any
such proposals.

Regards,

George P. Banyard

--0000000000000eecf005dc89cf00--