Re: [PHP-DEV] Changing fundamental language behaviors

This is only part of a thread. view whole thread
  106986
September 12, 2019 17:33 matthewmatthew@gmail.com (Matthew Brown)
> > 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.
>
  106989
September 12, 2019 17:41 chasepeeler@gmail.com (Chase Peeler)
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
  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.

>
  106991
September 12, 2019 17:54 chasepeeler@gmail.com (Chase Peeler)
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". > > I call shenanigans on that 95% number. Can you please back that up?
Personally, I don't think it's even possible to gauge userland support because the vast majority of userland developers aren't involved in the community at all. Those people don't even know this is being discussed, and probably won't until they start looking to upgrade to PHP 8.
> 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. > >>
-- Chase Peeler chasepeeler@gmail.com
  106993
September 12, 2019 17:58 oludonsexy@gmail.com (Olumide Samson)
On Thu, Sep 12, 2019 at 6:54 PM 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". > > > > > I call shenanigans on that 95% number. Can you please back that up? > Personally, I don't think it's even possible to gauge userland > support because the vast majority of userland developers aren't involved in > the community at all. Those people don't even know this is being discussed, > and probably won't until they start looking to upgrade to PHP 8. > > I'm sure you need to read the message properly before replying, he ain't talking about PHP there...
Even 95% can be called anything(of users who are involved in the community, who knows, who are actual users, etc)
> > > 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. > > > >> > > -- > Chase Peeler > chasepeeler@gmail.com >
  106999
September 12, 2019 18:11 chasepeeler@gmail.com (Chase Peeler)
On Thu, Sep 12, 2019 at 1:58 PM Olumide Samson <oludonsexy@gmail.com> wrote:

> > > On Thu, Sep 12, 2019 at 6:54 PM 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". >> > >> > >> I call shenanigans on that 95% number. Can you please back that up? >> Personally, I don't think it's even possible to gauge userland >> support because the vast majority of userland developers aren't involved >> in >> the community at all. Those people don't even know this is being >> discussed, >> and probably won't until they start looking to upgrade to PHP 8. >> >> I'm sure you need to read the message properly before replying, he ain't > talking about PHP there... > > Even 95% can be called anything(of users who are involved in the > community, who knows, who are actual users, etc) > >> >> No, I think you misunderstood. I said "What if Java did XYZ" - The reply
was "If 95% of userland Java developers supported such a change..." That implies that 95% of userland PHP developers support the changes in the RFC. It wouldn't make sense to say "Well, if 95% of Java userland developers supported the change, then it would make sense, just like we should pass this RFC that 45% of PHP userland developers support"
> > 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. >> > >> >> >> >> -- >> Chase Peeler >> chasepeeler@gmail.com >> >
-- Chase Peeler chasepeeler@gmail.com