Re: Long-Term Planning for PHP 9.0 Error Promotion

From: 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

« previous php.internals (#116948) next »