Re: [PHP-DEV] Changing fundamental language behaviors

This is only part of a thread. view whole thread
  106992
September 12, 2019 17:57 php-lists@koalephant.com (Stephen Reay)
> On 13 Sep 2019, at 00:41, Chase Peeler <chasepeeler@gmail.com> wrote: > > On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown <matthewmatthew@gmail.com> > wrote: > >> What if Java suddenly said that all properties are suddenly private, and >>> can only be accessed through getter/setter methods? >>> >> >> If Java announced that the next major version was to make the change after >> 95% of userland developers favoured it and over 2/3rds of their internals >> team did, I'd think "huh ok I guess they have good reasons". >> >> For 20 years people have developed code based on that feature. It was >>> never considered an error, and often not even considered bad practice >> >> >> You seem to be arguing against *ever* changing something that a majority >> once thought was good, and fundamental to a given system. Lots of things >> fall into that category - restricting voting to men, segregation, etc. >> > > Now you're just being silly. I actually don't have a problem with > fundamental language change, provided that the positives that are gained > far outweigh the negatives of the BC break and there is no other way to > accomplish those positives without such a BC break. > > There are a myriad of ways to achieve what the RFC attempts to achieve. > Whether that's analysis tools, custom error handlers, detailed code > reviews, etc. Nothing prevents anyone from initializing all of their > variables or performing as many sanity checks on a variable before > accessing it as they want to. Nothing in the RFC is required to implement > other new functionality like enums, union types, variable typing, etc. > > I also think it's a bit of a stretch to compare something like variable > initialization with things that denied people their basic human rights. > > -- > Chase Peeler > chasepeeler@gmail.com
Please, will someone arguing against making use of undefined variables a higher severity, explain to me why the same argument was not made for use of undefined constants, for which the RFC to deprecate/remove support, passed 41:0. How is one undefined symbol more acceptable than another undefined symbol?
  106996
September 12, 2019 18:07 chasepeeler@gmail.com (Chase Peeler)
On Thu, Sep 12, 2019 at 1:58 PM Stephen Reay <php-lists@koalephant.com>
wrote:

> > > On 13 Sep 2019, at 00:41, Chase Peeler <chasepeeler@gmail.com> wrote: > > > > On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown <matthewmatthew@gmail.com> > > wrote: > > > >> What if Java suddenly said that all properties are suddenly private, and > >>> can only be accessed through getter/setter methods? > >>> > >> > >> If Java announced that the next major version was to make the change > after > >> 95% of userland developers favoured it and over 2/3rds of their > internals > >> team did, I'd think "huh ok I guess they have good reasons". > >> > >> For 20 years people have developed code based on that feature. It was > >>> never considered an error, and often not even considered bad practice > >> > >> > >> You seem to be arguing against *ever* changing something that a majority > >> once thought was good, and fundamental to a given system. Lots of things > >> fall into that category - restricting voting to men, segregation, etc. > >> > > > > Now you're just being silly. I actually don't have a problem with > > fundamental language change, provided that the positives that are gained > > far outweigh the negatives of the BC break and there is no other way to > > accomplish those positives without such a BC break. > > > > There are a myriad of ways to achieve what the RFC attempts to achieve. > > Whether that's analysis tools, custom error handlers, detailed code > > reviews, etc. Nothing prevents anyone from initializing all of their > > variables or performing as many sanity checks on a variable before > > accessing it as they want to. Nothing in the RFC is required to implement > > other new functionality like enums, union types, variable typing, etc. > > > > I also think it's a bit of a stretch to compare something like variable > > initialization with things that denied people their basic human rights. > > > > -- > > Chase Peeler > > chasepeeler@gmail.com > > > Please, will someone arguing against making use of undefined variables a > higher severity, explain to me why the same argument was not made for use > of undefined constants, for which the RFC to deprecate/remove support, > passed 41:0. > > How is one undefined symbol more acceptable than another undefined symbol?
First of all, I wasn't as involved with this list back then as I was now. However, I can see a fundamental difference in the two. Not needing to initialize variables just for the sake of initializing them (e.g. just doing $i++ without $i=0 before it) is something that is going to behave as expected almost all of the time. When it doesn't, you can easily initialize $i to a non-zero value, or, you can initialize it to zero if you want - it doesn't hurt anything. An undefined constant getting converted to a string, though, is much less likely to be the intended behavior. String literals are required to be in quotes. Constants can never be in quotes. Assuming that the token that looks like a constant, but can't be because the constant didn't exist, so, we'll pretend it's a string even though it doesn't match the proper syntax for such a token is drastically different than assuming the variable you are incrementing that wasn't initialized is 0, or, that the variable you are concatenating to, but wasn't initialized, is an empty string. Finally, let's pretend that the undefined constants RFC was a horrible RFC that shouldn't have passed. The fact that it did has no impact on whether or not this RFC should pass. -- Chase Peeler chasepeeler@gmail.com
  107002
September 12, 2019 18:24 php-lists@koalephant.com (Stephen Reay)
> On 13 Sep 2019, at 01:07, Chase Peeler <chasepeeler@gmail.com> wrote: > > > > On Thu, Sep 12, 2019 at 1:58 PM Stephen Reay <php-lists@koalephant.com> wrote: > > > On 13 Sep 2019, at 00:41, Chase Peeler <chasepeeler@gmail.com> wrote: > > > > On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown <matthewmatthew@gmail.com> > > wrote: > > > >> What if Java suddenly said that all properties are suddenly private, and > >>> can only be accessed through getter/setter methods? > >>> > >> > >> If Java announced that the next major version was to make the change after > >> 95% of userland developers favoured it and over 2/3rds of their internals > >> team did, I'd think "huh ok I guess they have good reasons". > >> > >> For 20 years people have developed code based on that feature. It was > >>> never considered an error, and often not even considered bad practice > >> > >> > >> You seem to be arguing against *ever* changing something that a majority > >> once thought was good, and fundamental to a given system. Lots of things > >> fall into that category - restricting voting to men, segregation, etc. > >> > > > > Now you're just being silly. I actually don't have a problem with > > fundamental language change, provided that the positives that are gained > > far outweigh the negatives of the BC break and there is no other way to > > accomplish those positives without such a BC break. > > > > There are a myriad of ways to achieve what the RFC attempts to achieve. > > Whether that's analysis tools, custom error handlers, detailed code > > reviews, etc. Nothing prevents anyone from initializing all of their > > variables or performing as many sanity checks on a variable before > > accessing it as they want to. Nothing in the RFC is required to implement > > other new functionality like enums, union types, variable typing, etc. > > > > I also think it's a bit of a stretch to compare something like variable > > initialization with things that denied people their basic human rights. > > > > -- > > Chase Peeler > > chasepeeler@gmail.com > > > Please, will someone arguing against making use of undefined variables a higher severity, explain to me why the same argument was not made for use of undefined constants, for which the RFC to deprecate/remove support, passed 41:0. > > How is one undefined symbol more acceptable than another undefined symbol? > > First of all, I wasn't as involved with this list back then as I was now. However, I can see a fundamental difference in the two. Not needing to initialize variables just for the sake of initializing them (e.g. just doing $i++ without $i=0 before it) is something that is going to behave as expected almost all of the time. When it doesn't, you can easily initialize $i to a non-zero value, or, you can initialize it to zero if you want - it doesn't hurt anything. > > An undefined constant getting converted to a string, though, is much less likely to be the intended behavior. String literals are required to be in quotes. Constants can never be in quotes. Assuming that the token that looks like a constant, but can't be because the constant didn't exist, so, we'll pretend it's a string even though it doesn't match the proper syntax for such a token is drastically different than assuming the variable you are incrementing that wasn't initialized is 0, or, that the variable you are concatenating to, but wasn't initialized, is an empty string. > > Finally, let's pretend that the undefined constants RFC was a horrible RFC that shouldn't have passed. The fact that it did has no impact on whether or not this RFC should pass. > > -- > Chase Peeler > chasepeeler@gmail.com
Apologies if you thought I was specifically replying to you Chase, I simply hit reply-all to the last message I had. The RFC I referred to explicitly describes the use-case for the (mis-)feature it removed:
> The current behaviour appears to have been added as an attempt to guess the user's intention, and continue gracefully.
Sounds familiar, doesn’t it? “If I write $foo++ and $foo is undefined, it should know what I mean”.
> The value of keeping the current behaviour would be for programs written to deliberately take advantage of it. In particular, I have seen sample code of the form $_GET[bar] where bar is taken to be the string key bar.
So, it clearly was (ab)used. IMO this also flies in the face of the “we can’t change behaviour” argument - bare word strings were added around 20 years ago, and yet not a single person thought it worthwhile voting against the deprecation and removal of this behaviour?
  107003
September 12, 2019 18:25 matthewmatthew@gmail.com (Matthew Brown)
I'm sure that some people wrote code like this, expecting it to always work
in PHP:

if ($some_condition) define("HELLO", 0);
if (HELLO) { var_dump("got here"); }

The equivalent, relying on buggy behaviour, PHP code looks like

if ($some_condition) $hello = 1;
if (!$hello) { var_dump("got here"); }

If preventing undefined constants wasn't a fundamental change to the
language, neither is preventing undefined variables.

>