Re: Changing fundamental language behaviors

From: Date: Thu, 12 Sep 2019 17:57:50 +0000
Subject: Re: Changing fundamental language behaviors
References: 1 2 3 4 5 6 7 8 9  Groups: php.internals 
Request: Send a blank email to internals+get-106992@lists.php.net to get a copy of this message
> 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?

« previous php.internals (#106992) next »