Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116560
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> <CAESVnVrS71=cBztkXY3HQ_HQuLKMnzk6=vdYQ5p4Gb6KR-xJQg@mail.gmail.com>
In-Reply-To: <CAESVnVrS71=cBztkXY3HQ_HQuLKMnzk6=vdYQ5p4Gb6KR-xJQg@mail.gmail.com>
Date: Thu, 2 Dec 2021 17:28:45 +0000
Message-ID: <CAFv4g+Fu51RDnFVe=UszT10TNWnupSzy7cmA3nYmRowor7tb8A@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000045ae905d22d2085"
Subject: Re: [PHP-DEV] Allowing NULL for some internal functions
From: craig@craigfrancis.co.uk (Craig Francis)

--000000000000045ae905d22d2085
Content-Type: text/plain; charset="UTF-8"

On Thu, 2 Dec 2021 at 15:19, Sara Golemon <pollita@php.net> wrote:

> 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?
>


Thanks, I'll start by creating a list of functions I think apply (anyone
who has any suggestions, please let me know... I'm just going to look at
some log files to get started... or try to work out if
`Z_PARAM_STRING_OR_NULL` vs `Z_PARAM_STR` / `Z_PARAM_STRING` can give me a
list of functions to look though).


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?
>


While I think unifying can help in some cases, there is a lot of existing
code where developers have used the null coalesce operator to return NULL
(either out of habit, or because they need to determine the difference
between an empty string vs an unset value)... the main source being the
functions frameworks have provided to return GPC values, e.g.


   - Laravel: $request->input('name');
   - Symfony: $request->get('name');
   - CakePHP: $this->request->getQuery('name');
   - CodeIgniter: $request->getGet('name');


As to the search example... I've seen one project where the search pages
would only show the form at first (when null); then, when the user did a
search, it showed the search form again, the results table (where an empty
string would show all records, useful to see the total number of records),
and present additional filtering fields (done like this for performance
reasons).

That's not to say all of these examples can't be updated to work, but there
will be a lot to change... like one project which had simply used `trim()`
to remove whitespace from some user inputs, where the fields/values are
normally present, but because NULL can happen (even via odd things, like
the user being on a slow connection and the form not loading completely),
it's now a problem.

Thanks again,
Craig

--000000000000045ae905d22d2085--