Re: Long-Term Planning for PHP 9.0 Error Promotion
| From: | Craig Francis | Date: | Wed, 26 Jan 2022 16:42:41 +0000 |
| Subject: | Re: Long-Term Planning for PHP 9.0 Error Promotion | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-116931@lists.php.net to get a copy of this message | ||
On Mon, 24 Jan 2022 at 23:47, Mark Randall <marandall@php.net> wrote:
> Let's open a discussion as to what we might want to do in the future,
> and depending on how things shake out, we can decide what route to take
> with regards to bringing RFCs to vote.
>
While I did begin an RFC to allow *some* functions to be more tolerant of
NULL, especially for those scripts not using
strict_types:
https://wiki.php.net/rfc/allow_null
Or in other words, to "relax certain type requirements on a case by case
basis", ref the original discussion:
https://externals.io/message/112327
The only feedback I've received is that it's a "terrible idea" (no
details), "it's a bit late" (deprecations have already been issued, full
steam ahead?), and the typical objections/negativity (-4 points on
externals.io, not quite a record, but getting there).
The view seems to be that every single PHP developer must use *strict*
static analysis (e.g. Psalm at levels 1 to 3, with no baseline), and tools
like Rector or PHPCompatibility (neither of which handle this problem;
where I'll note that it will be hard to do, as it involves tracking every
single variable from source to sink).
While I'm not a C programmer, I was just thinking of replacing some uses of
Z_PARAM_STR with something similar to Z_PARAM_STR_OR_NULL, maybe
calling it Z_PARAM_STR_ALLOW_NULL, where it would return an empty string
for NULL with scripts not using strict_types... but I got the impression
this would be unacceptable.
So I assume, with this PHP 9.0 discussion, we should just get on with this
ideological purity, move on from deprecation, and raise a Fatal Error for
everyone committing heinous crimes such as:
echo htmlspecialchars($name);
Where $name might contain NULL, due to using something like
($_GET['name'] ?? NULL), as used by some minor frameworks
like Laravel, Symfony, CakePHP, CodeIgniter, etc - a pattern used to denote
a value not being provided by the user.
As an aside, I love how the RFC template includes this example quote from
Rasmus:
> PHP is and should remain:
> 1) a pragmatic web-focused language
> 2) a loosely typed language
> 3) a language which caters to the skill-levels and platforms of a wide
range of users
And, yes, I am venting, but who cares, I'm not going to change anyones mind.
Craig