> On 13 Sep 2019, at 01:07, Chase Peeler <chasepee...@gmail.com> wrote: > > > > On Thu, Sep 12, 2019 at 1:58 PM Stephen Reay <php-li...@koalephant.com> wrote: > > > On 13 Sep 2019, at 00:41, Chase Peeler <chasepee...@gmail.com> wrote: > > > > On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown <matthewmatt...@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 > > chasepee...@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 > chasepee...@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? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
