Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116989
MIME-Version: 1.0
References: <CAFv4g+Efz-V5V1uUedXpusNw6z-on=TT3kdWgC66SptSd8kB4g@mail.gmail.com>
 <CAFv4g+HvM5CPw6DNdsipYmZEb3zjWY2_Use4O+yfxAPBedzFUw@mail.gmail.com> <6200d9ef.1c69fb81.38c1f.3f07SMTPIN_ADDED_MISSING@mx.google.com>
In-Reply-To: <6200d9ef.1c69fb81.38c1f.3f07SMTPIN_ADDED_MISSING@mx.google.com>
Date: Mon, 7 Feb 2022 09:52:54 +0100
Message-ID: <CANS-=peRJrrxFobk0XqodyL4dUsVs=0AsU1QabMwhOFhzd00nw@mail.gmail.com>
To: Mark Randall <marandall@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000737f9c05d769bb0e"
Subject: Re: [PHP-DEV] Allowing NULL for some internal functions
From: kjarli@gmail.com (Lynn)

--000000000000737f9c05d769bb0e
Content-Type: text/plain; charset="UTF-8"

On Mon, Feb 7, 2022 at 9:35 AM Mark Randall <marandall@php.net> wrote:

> On 07/02/2022 01:27, Craig Francis wrote:
> > I know one person simply said this was a "terribl > idea", but I'm still
> > waiting to hear any details on why.
>
> The changes you propose are not something that I am comfortable with
> either.
>
> I understand your motivations in proposing them, but to my mind it goes
> against the direction that PHP is developing, which I think is the right
> one, where errors and likely errors result in stopping execution rather
> than allowing it continue, potentially silently (dependent on error
> handling settings).
>
> If a parameter expects a string, that is what it should be given, and
> its the callers' responsibility to ensure that is the case. If they fail
> to do so then it's an error just like any other.
>
> IMHO reverting to "If it's a null we'll just pretend its a string" is
> contrary to how the language should be progressing.
>
> It sucks that it was ever allowed in the first place.
>
> PHP has a long history of making descisions to try to make things 'just
> work', and if history teaches us anything, its that we inevitably come
> to regret these descisions down the line.
>

I agree with this sentiment. I rather see solutions that solve null values
being passed to these functions instead. The in-house legacy framework I
use has a small array wrapper that through `ArrayAccess` ensures `null` is
returned instead of a notice/warning being thrown when accessing a key that
does not exist. During `offsetGet` it will return itself wrapped around the
value if it's an array. I'm not saying that this is a good alternative for
the problem, it's just one of the solutions that can be taken to tackle
issues with `$_POST` and `$_GET` access for example.

--000000000000737f9c05d769bb0e--