Re: [RFC Proposal] var keyword deprecation/removal

From: Date: Mon, 07 Mar 2016 19:02:30 +0000
Subject: Re: [RFC Proposal] var keyword deprecation/removal
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15  Groups: php.internals 
Request: Send a blank email to internals+get-91530@lists.php.net to get a copy of this message
On Mon, Mar 7, 2016 at 4:27 AM, <kelerest123@gmail.com> wrote: > > Change for the sake of change is bad, no argument there. Change for the > > > sake of progress is not and totally normal. > > > > Can you please specify what kind of progress do see in the var > keyword > removal? I see only a BC break. > > > > > Very best regards, > Kubis Pandian-Fowler > > > > > > > Od: Fleshgrinder > Odoslané: ‎štvrtok‎, ‎3‎. ‎marca‎ ‎2016 ‎22‎:‎23 > Komu: internals@lists.php.net > > > > > > On 3/3/2016 10:34 AM, Tony Marston wrote: > > If you want to avoid such confusion over alias names then surely that > > would be an argument against introducing aliases in the first place. In > > this case the short array syntax would never have been introduced as the > > (only slightly longer) long array syntax had already existed since day > #1. > > No, that is not what one should conclude from it. Short array syntax was > added by popular demand and hence for a very good reason. The fact that > there are no plans regarding the old syntax and thus keeping the > duplication indefinitely is the actual problem. > > Change for the sake of change is bad, no argument there. Change for the > sake of progress is not and totally normal. > > On 3/3/2016 2:04 PM, Rowan Collins wrote: > > I'm not sure what Lester had in mind, but in many cases legacy code > > which used "var" should actually be updated to mark properties as > > "protected" or "private" instead. Such properties are public only > > because PHP4 had no other visibility, and explicitly marking them all > > "public" simply masks the real job, which is assessing which > > visibility each property should have. > > > > It occurs to me that if I saw "var", I would not think "that should be > > public", but "that needs assessing for visibility". I do the same with > > legacy code where methods are written as "function foo()" rather than > > "public function foo()" - I check whether it should actually be > > public, and also in that case whether it should be static. > > It seems as if this is not the issue for the people who are against > removing the "var" keyword from PHP 8. They simply do not want to change > their scripts at all. The described procedure is truly time consuming > since it involves to check all usages everywhere as well. Simply > changing from "var" or "public" to any other visibility is a brutal change. > > -- > Richard "Fleshgrinder" Fussenegger > It is a disagreement over language design, the Python way vs the Perl way. The Perl way says: There is more than one way to do things The Python way says: There is one correct way to do things. Other methods should be removed. There is a desire among some PHP people to have the language be more like the Python mindset. -- The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis

« previous php.internals (#91530) next »