Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116561
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: Fri, 3 Dec 2021 00:32:02 +0700
Message-ID: <CAEZPtU7CmALZOrphRPehpJF6aYUeZmDgsEmzghPdGaQJ+iv87A@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: Craig Francis <craig@craigfrancis.co.uk>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e8482805d22d2bcc"
Subject: Re: [PHP-DEV] Allowing NULL for some internal functions
From: pierre.php@gmail.com (Pierre Joye)

--000000000000e8482805d22d2bcc
Content-Type: text/plain; charset="UTF-8"

On Thu, Dec 2, 2021, 10:20 PM 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?
>
> 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?
>


I wonder what is the technical benefit from that?

I do feel we are moving to a strict typed language. If that is what is
desired, then let decide it clearly and move forward to rhst direction.

best,
Pierre

>

--000000000000e8482805d22d2bcc--