Re: Long-Term Planning for PHP 9.0 Error Promotion
| From: | Christian Schneider | Date: | Sat, 29 Jan 2022 16:33:13 +0000 |
| Subject: | Re: Long-Term Planning for PHP 9.0 Error Promotion | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-116948@lists.php.net to get a copy of this message | ||
Am 28.01.2022 um 23:57 schrieb Jordan LeDoux <jordan.ledoux@gmail.com>:
>
> On Thu, Jan 27, 2022 at 12:24 AM Christian Schneider <cschneid@cschneid.com
> <mailto:cschneid@cschneid.com>> wrote:
>
> My issue with this is that while it seems to work towards the goal of "fail fast" it
> does not completely fulfill its promise.
>
>
> Pardon me, but this argument seems rather impotent. Only fully realized features are allowed?
> What if there is not agreement on the details of some of the edgecases? Something better should be
> rejected because it's not something perfect?
I was probably too brief there, let me elaborate a bit.
An error on reading an undefined variable does the "fail" part. And it partially delivers
on the "fast" part as it fails at the first access, not at a later point.
But, and that was my point, it is still failing at runtime, maybe long after deployment if it is in
an obscure code path.
If a static analyzer manages to catch it at development time then that is a lot better.
This has an impact on how I evaluate the positive effect of error-on-undefined and so far my
conclusion was a net-negative compared to the current situation.
Side-note: An additional downside of having the increased safety net on reading undefined variables
can be that developers think they do not need to have other checks like a static analyzers which
might do an even better job to make their code better. But that's not my main point.
- Chris