Re: Allowing NULL for some internal functions

From: Date: Wed, 02 Mar 2022 14:58:25 +0000
Subject: Re: Allowing NULL for some internal functions
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15  Groups: php.internals 
Request: Send a blank email to internals+get-117211@lists.php.net to get a copy of this message
On 02.03.22 15:27, Craig Francis wrote:
On Wed, 2 Mar 2022 at 14:17, Larry Garfield <larry@garfieldtech.com> wrote:
Null is not an empty string. Null is not a string. Null is not 0. Null is not an integer.
So what should this do? $name = ($_POST['name'] ?? NULL); var_dump($name == ''); Is that now going to be false? Comparisons with == are quite worthless, except when comparing objects,
as == has so many caveats for when it returns true because of weird rules about what should be considered equal or not for legacy reasons. I don't think I have used == in the last 5 years, and life has gotten so much better because of it. Why not write: $name = ($_POST['name'] ?? ''); Then you know 100% that $name does not contain null. It might not be a string, but it cannot be null. You can still not safely pass it to something like htmlentities or str_starts_with, because $name could be an array. And I think that is the reason why the current deprecation and eventual removal makes sense - it highlights missing logic that can easily lead to errors. If the problem is not null, then it might be that you have another unexpected type like an array, because the value was not properly checked. Putting strval around such code (as one possibility to resolve it) at least improves the code, in that we then have a clear type for the variable, removing some room for errors and bugs..

« previous php.internals (#117211) next »