Re: Changing fundamental language behaviors

> 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?