Hi,
> So what we're talking about here is changing the engine's definition of
> what is safe
One of the benefits of PHP is it's resilience in the face of user input.
The
only time this isn't desired is in a security context (SQL queries,
authentication, etc). Most applications are not operating in a security
context 100% of the time so your definition of "safe" may not be
appropriate for other people's projects.
> I would posit that the vast majority of reads
> on undefined variables are in fact unintentional side effects from
> branching logic and are not the real intention at all.
I would posit differently. In my experience in upgrading code, it was
mostly intentional.
Here's an example:
----
if($doThing) {
$doOtherThing = maybe();
}
// later
if($doOtherThing) {
doOtherThing();
}
---
There's no bug here, nothing is unintentional, and the intent is clear. Now,
if we want to get rid of the warning we need to say $doOtherThing = false
before getting to the first if-statement, but should this halt everything in
production? I don't personally think so and it would be undesirable for it
to do so.
Robert Landers
Software Engineer
Utrecht NL
On Thu, Jan 27, 2022 at 11:41 PM Mark Randall <marand...@php.net> wrote:
> On 27/01/2022 22:09, Larry Garfield wrote:
> > I am not sure what additional value is gained by making the scream even
> louder.
>
> For us to make something an exception at engine level, is to stop
> execution on the grounds that the engine no longer considers it safe to
> continue.
>
> That might be because a boolean was passed to a function that expects a
> string, or in this case it might be because an undefined variable has
> been read.
>
> Notices / Warnings are irrelevant to this under the default
> configuration, as in the absense of a userland error handler the engine
> will happily allow code to continue executing even after a probably
> undesirable state has been detected.
>
> So what we're talking about here is changing the engine's definition of
> what is safe to exclude read operations on an undefined variable.
>
> I understand the argument that the behaviour is well defined, at least
> for some operations, but I would posit that the vast majority of reads
> on undefined variables are in fact unintentional side effects from
> branching logic and are not the real intention at all.
>
> If someone is insistent on working with nulls, there is an easy to use,
> fully backwards compatible way to avoid these errors, which is to define
> a variable as null prior to any branching logic.
>
> For everyone else, we should offer this entirely sensible safety net.
>
> What we don't want to do, I think, is end up in a situation like JS
> where it has to be opted in: https://www.w3schools.com/js/js_strict.asp
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
