Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

[Robert Landers]

Hi,

> You're not going to convince me that not initializing variables is a good
> thing

Personally, I don't think uninitialized variables are a "good thing" but I
also don't think they're a "bad thing" either.
I'd just like to see it not matter when writing a simple one-off script.
FWIW, C# has gone the way of making initializing
variables simpler and simpler over the years, almost to the point of not
being required.

The fact that PHP fires a warning now is probably enough for anyone writing
any code. If people choose to ignore warnings
they're free to do that. Though I suppose they're also free to fork PHP and
remove the thrown error too :D

> > There's no bug here, nothing is unintentional, and the intent is clear
>
> I cannot guarantee there's no bug, I cannot guarantee that this is
intentional, and the intent is certainly not clear. I can't tell
> whether or not this code is suffering from a merge conflict, and I cannot
guarantee that whatever type `maybe();` returns
> here works. If at some point the return type of `null` is changed to
`false`, while the assumption of undefined is `null`,
> passing `false` to a nullable typed argument later on will break.

That's what unit tests are for. ;) I can count on one hand the number of
times I've seen a bad merge in my entire 15+ year career,
so that wouldn't be an immediate conclusion I'd come to when seeing
something like this. It's much more likely it would be
intentional than not (without checking the history), but I probably
wouldn't bother in this case. If tests pass, don't fix it... just add
more tests.

> Our ecosystem of static analysers are fantastic, but they're standalone
> tools outside the remit of internals.

I think you hit the nail on the head Mark. I'd really love to see PHP have
a bundled static analysis tool.

Robert Landers
Software Engineer
Utrecht NL


On Sat, Jan 29, 2022 at 11:55 PM Lynn  wrote:

> On Sat, Jan 29, 2022 at 8:58 PM Christian Schneider  >
> wrote:
>
> > Am 29.01.2022 um 20:03 schrieb Mark Randall :
> > > On 29/01/2022 16:33, Christian Schneider wrote:
> > >> If a static analyzer manages to catch it at development time then that
> > is a lot better.
> > >
> > > Of course it's better, but you wouldn't argue that a car doesn't need
> > airbags because you've tested that the breaks work.
> >
> > To stay with your car analogy: A driving assistant system (especially
> when
> > wrongly interpreted as auto-pilot) can lead drivers to not paying
> attention
> > to the road any more. Which means even systems designed to help can have
> > negative effects.
> >
> > > With runtime checking, the engine should always try to protect against
> > the unexpected, irrespective of if other checking has already been
> > performed by outside sources.
> >
> > I think we've been over this: I don't think the engine should force me to
> > write too much unnecessary stuff just because I have to tell it I am
> sure I
> > mean what I wrote. There is a balance between explicit declarations and
> > conciseness, we just disagree where the sweet spot is.
> >
>
> To stay with the car analogy: Seatbelts were once considered unnecessary as
> well.
>
> Just because you know for sure you know you mean what you wrote, doesn't
> mean everyone else knows. They have to read the code you didn't write to
> know for sure.
>
> On Wed, Jan 26, 2022 at 7:16 PM Christian Schneider  >
> wrote:
>
> > Am 26.01.2022 um 18:37 schrieb Lynn :
> > > I don't understand how variable initializers are considered boilerplate
> > and make it easier to read without.
> >
> > [off-list as I think this has been discussed before]
> >
> > Example:
> >
> > function count_words($words)
> > {
> > foreach ($words as $word)
> > $counts[$word++];
> >
> > return (array)$counts;
> > }
> >
> > vs.
> >
> > Function count_words($words)
> > {
> > $words = [];# <-- Boilerplate
> > foreach ($words as $word)
> > {
> > $counts[$word] ??= 0;   # <-- Currently worse boilerplate
> > but beside your point
> > $counts[$word++];
> > }
> >
> > return $counts;
> > }
> >
> > I find the first version easier to understand but I guess we'll have to
> > agree to disagree here.
> >
> > Regards,
> > - Chris
>
>
> I would appreciate it if you keep the replies to the mailing list. Though
> while I'm at it, your examples are why it's important that we have PHP to
> let us know when things are broken.
>
> You're not going to convince me that not initializing variables is a good
> thing, I've had to fix way too much code where that kind of cowboy coding
> was at fault. As a reader I cannot see if the lack of a variable
> initialization is intentional, so I have to go through the history of the
> file to verify this behavior, and then I add the initialization so the next
> developer seeing this won't have to waste a lot of time by doing the same.
>
> A huge amount of changes in PHP are based 

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

[Lynn]

On Sat, Jan 29, 2022 at 8:58 PM Christian Schneider 
wrote:

> Am 29.01.2022 um 20:03 schrieb Mark Randall :
> > On 29/01/2022 16:33, Christian Schneider wrote:
> >> If a static analyzer manages to catch it at development time then that
> is a lot better.
> >
> > Of course it's better, but you wouldn't argue that a car doesn't need
> airbags because you've tested that the breaks work.
>
> To stay with your car analogy: A driving assistant system (especially when
> wrongly interpreted as auto-pilot) can lead drivers to not paying attention
> to the road any more. Which means even systems designed to help can have
> negative effects.
>
> > With runtime checking, the engine should always try to protect against
> the unexpected, irrespective of if other checking has already been
> performed by outside sources.
>
> I think we've been over this: I don't think the engine should force me to
> write too much unnecessary stuff just because I have to tell it I am sure I
> mean what I wrote. There is a balance between explicit declarations and
> conciseness, we just disagree where the sweet spot is.
>

To stay with the car analogy: Seatbelts were once considered unnecessary as
well.

Just because you know for sure you know you mean what you wrote, doesn't
mean everyone else knows. They have to read the code you didn't write to
know for sure.

On Wed, Jan 26, 2022 at 7:16 PM Christian Schneider 
wrote:

> Am 26.01.2022 um 18:37 schrieb Lynn :
> > I don't understand how variable initializers are considered boilerplate
> and make it easier to read without.
>
> [off-list as I think this has been discussed before]
>
> Example:
>
> function count_words($words)
> {
> foreach ($words as $word)
> $counts[$word++];
>
> return (array)$counts;
> }
>
> vs.
>
> Function count_words($words)
> {
> $words = [];# <-- Boilerplate
> foreach ($words as $word)
> {
> $counts[$word] ??= 0;   # <-- Currently worse boilerplate
> but beside your point
> $counts[$word++];
> }
>
> return $counts;
> }
>
> I find the first version easier to understand but I guess we'll have to
> agree to disagree here.
>
> Regards,
> - Chris


I would appreciate it if you keep the replies to the mailing list. Though
while I'm at it, your examples are why it's important that we have PHP to
let us know when things are broken.

You're not going to convince me that not initializing variables is a good
thing, I've had to fix way too much code where that kind of cowboy coding
was at fault. As a reader I cannot see if the lack of a variable
initialization is intentional, so I have to go through the history of the
file to verify this behavior, and then I add the initialization so the next
developer seeing this won't have to waste a lot of time by doing the same.

A huge amount of changes in PHP are based on what other languages do (or
sometimes rather don't). With the amount of the web that PHP powers, it's a
good thing that PHP grabs the good bits and improves itself. Ensuring that
variables are properly initialized is one of them, as it protects the
developers from making preventable mistakes without requiring external
tools.

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

[Christian Schneider]

Am 29.01.2022 um 20:03 schrieb Mark Randall :
> On 29/01/2022 16:33, Christian Schneider wrote:
>> If a static analyzer manages to catch it at development time then that is a 
>> lot better.
> 
> Of course it's better, but you wouldn't argue that a car doesn't need airbags 
> because you've tested that the breaks work.

To stay with your car analogy: A driving assistant system (especially when 
wrongly interpreted as auto-pilot) can lead drivers to not paying attention to 
the road any more. Which means even systems designed to help can have negative 
effects.

> With runtime checking, the engine should always try to protect against the 
> unexpected, irrespective of if other checking has already been performed by 
> outside sources.

I think we've been over this: I don't think the engine should force me to write 
too much unnecessary stuff just because I have to tell it I am sure I mean what 
I wrote. There is a balance between explicit declarations and conciseness, we 
just disagree where the sweet spot is.

I do for example admire the power of Haskell's type system but I would never 
want PHP to try to implement it.

Regards,
- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

[Mark Randall]

On 29/01/2022 16:33, Christian Schneider wrote:

If a static analyzer manages to catch it at development time then that is a lot 
better.


Of course it's better, but you wouldn't argue that a car doesn't need 
airbags because you've tested that the breaks work.


Defense in depth.

Our ecosystem of static analysers are fantastic, but they're standalone 
tools outside the remit of internals. Maybe that software has a bug, 
maybe it hasn't yet been programmed to recognise the side effects of a 
new feature that was added, maybe the user has not updated the library 
in a while.


With runtime checking, the engine should always try to protect against 
the unexpected, irrespective of if other checking has already been 
performed by outside sources.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

[Christian Schneider]

Am 28.01.2022 um 23:57 schrieb Jordan LeDoux :
> 
> On Thu, Jan 27, 2022 at 12:24 AM Christian Schneider  > 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