Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119114
Message-ID: <38E9E8ED-F266-4EFC-8E17-DDD60F45EADA@craigfrancis.co.uk>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_284ABF28-FE35-4C72-A43A-2300D1174BD0"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Date: Tue, 13 Dec 2022 10:11:50 +0000
In-Reply-To: <5fe0d8a9-d305-9c9d-ca36-1ca30de87b78@cubiclesoft.com>
Cc: PHP internals <internals@lists.php.net>
To: Thomas Hruska <thruska@cubiclesoft.com>,
 dliebner@gmail.com
References: <CAMXcktOiFH-0f0PG9cKkkVaczjNLSzQzzPUBcoLyn54X=c74og@mail.gmail.com>
 <D494A14E-0733-406B-844E-DD2D3FBB7EB4@php.net>
 <5fe0d8a9-d305-9c9d-ca36-1ca30de87b78@cubiclesoft.com>
Subject: Re: [PHP-DEV] Revisiting RFC: Engine Warnings -- Undefined array
 index
From: craig@craigfrancis.co.uk (Craig Francis)

--Apple-Mail=_284ABF28-FE35-4C72-A43A-2300D1174BD0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On 12 Dec 2022, at 23:36, Thomas Hruska <thruska@cubiclesoft.com> wrote:
> I suspect many people are in a similar holding pattern who are =
currently running packaged 7.4.x and are just now discovering all of the =
changes for PHP 8.x as they are planning out their system upgrade paths =
in the coming months.  While you probably wish everyone marched in step =
with PHP-latest, that's simply not feasible in reality.


Hi Thomas, Dan,

I know a few teams that have started using 8.x on their development =
servers (while 7.x is still on demo/live). Each team has their =
difficulties, but fortunately most issues can be ignored for now (as in, =
code works, and gives you time to make changes)... undefined indexes are =
a classic, but once you've found them all (the tricky bit), it often =
makes your code better, and helps identify mistakes (similar to =
undefined variables).

But, the one change I still cannot justify, is the deprecation of null =
being passed to the ~335 functions like htmlspecialchars. The null value =
can come from many sources (e.g. GET/POST/COOKIE/databases), and while =
you can still use null coercion in contexts like string concat (empty =
string), arithmetic (the value 0), or a boolean (false); finding all the =
function calls is incredibly hard (one team I work with, who has a =
fairly good test coverage, is still finding these over a year later)... =
at least it can be ignored for 8.x, but it's going to be a nightmare for =
9.0... I tried writing an RFC to revert this change (considering there =
was pretty much no discussion went into it, and I cannot find a benefit =
for breaking coercion in this one context), but it was met with a lot of =
hostility from internals, so I'm finding ways to work around it, because =
I don't like systems using old/unsupported software (and I've got some =
ugly hacks for it, like using the latest version of Rector to flood your =
code base with `(string) $var`, or to use a namespace).

Craig


https://wiki.php.net/rfc/null_coercion_consistency =
<https://wiki.php.net/rfc/null_coercion_consistency>
https://externals.io/message/117501 =
<https://externals.io/message/117501>




null_coercion.php
<?php

namespace null_coercion;

function strlen(?string $string): int {
    return \strlen((string) $string);
}
// x335 functions

?>



index.php
<?php

namespace null_coercion;
require_once('null_coercion.php'); // Probably can be auto-loaded.

echo strlen('AAA');
echo strlen(NULL);
echo strlen(12);
echo strlen(false);

?>=

--Apple-Mail=_284ABF28-FE35-4C72-A43A-2300D1174BD0--