Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116557
MIME-Version: 1.0
References: <CALp5e-8xoj-RTcvmvDZ68c0pgAJBUcKhkLwZxNLspYhY6G6qEw@mail.gmail.com>
 <CAGBsUrcVjNmOJk8DnOmWzfmr5vVgjWbDzj-bYv1QGDXSdJz=Cw@mail.gmail.com>
 <CALp5e-8=sbQo1rCNW_Hf0Tw6v4PtPss7L9GoHq6XTev8Wh97=g@mail.gmail.com>
 <CA+kxMuRdb2DDNteEn1Os7T5dc-5gUCQ=eTB9Bfr7AA5bb4q2jg@mail.gmail.com>
 <CALp5e-92Te1ZmSKXubG45Fw1nznyiN2sN_LmycYZ1Dxb2YFQ4g@mail.gmail.com>
 <CAESVnVqD+9w=_qhh2ADD9WM0YqmGP_X0Qpfd8qZonbP2wZ4G_Q@mail.gmail.com> <CAFv4g+FCcOb6WWWPkzQhTmvMAj8p2vQGLDK5OymrykQkKYE8UA@mail.gmail.com>
In-Reply-To: <CAFv4g+FCcOb6WWWPkzQhTmvMAj8p2vQGLDK5OymrykQkKYE8UA@mail.gmail.com>
Date: Thu, 2 Dec 2021 09:19:33 -0600
Message-ID: <CAESVnVrS71=cBztkXY3HQ_HQuLKMnzk6=vdYQ5p4Gb6KR-xJQg@mail.gmail.com>
To: Craig Francis <craig@craigfrancis.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f8bb7805d22b51d0"
Subject: Re: [PHP-DEV] Allowing NULL for some internal functions
From: pollita@php.net (Sara Golemon)

--000000000000f8bb7805d22b51d0
Content-Type: text/plain; charset="UTF-8"

On Thu, Dec 2, 2021 at 8:48 AM Craig Francis <craig@craigfrancis.co.uk>
wrote:

> On Fri, 26 Nov 2021 at 16:47, Sara Golemon <pollita@php.net> wrote:
>
> > I'm not saying send PRs to fix them all...  Let's make PHP better,
> > together.
>
>
>
> On a similar theme, trying to avoid too much work for developers upgrading
> to later versions of PHP.
>
> Is there any value in me proposing an RFC to update *some* internal
> functions so they can accept NULL?
>
> I see developers using their framework of choice for GET/POST/COOKIE/etc
> values (where they receive NULL to represent unset values), or simply doing
> `$q = ($_GET['q'] ?? NULL)`, and other sources... where they will now get
> deprecation messages whenever they use functions like `htmlspecialchars()`,
> `trim()`, `strpos()`, `strtoupper()`, `strlen()`.
>
>
I'm not hard against this idea.  The interpretation of null in these
contexts as being equivalent to empty string isn't unreasonable.  I guess
the only objection I could have would be an academic one and I can't really
defend that.  So yeah, sure... why not?

I would say that such applications should consider unifying their own
types.  $a = $_GET['q'] ?? '';   Is there a place in the application where
empty string and null would have been distinct? i.e. Is a search for
nothing different from not searching?

-Sara

--000000000000f8bb7805d22b51d0--