Re: [RFC Proposal] var keyword deprecation/removal
| From: | Tony Marston | Date: | Fri, 26 Feb 2016 09:46:52 +0000 |
| Subject: | Re: [RFC Proposal] var keyword deprecation/removal | ||
| Groups: | php.internals | ||
| Request: | Send a blank email to internals+get-91430@lists.php.net to get a copy of this message | ||
Sent: Thursday, February 25, 2016 12:58 PM
To: Tony Marston Subject: Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal Hi Tony, Thank you so much for your feedback. You make some really good, valid points. If I may provide some responses to some of them:So you examined a bunch of source files in one location? What about those projects that aren't maintained on Packagist? Mine certainly isn't.Where is your proof? You say "not used by a major part of the community" which means that it is still being used by a minor part, but exactly how "minor"?I downloaded and scanned the top 10,000 projects on Packagist (including their dependencies).
Only 4% use "var". I looked closer into that 4% and found almost 2/3rds were due to a handful of prominent packages being required as dependencies. Adjusting these packages would drastically lower overall usage across the ecosystem. And because "var" is simply an alias for "public", making that change would only require a bump in the patch version. I'm not 100% happy with my methodology because the dependencies are counted multiple times. When I have some time I'll revise my approach to get more-accurate figures.The only way to obtain what could be called "accurate" figures would be to examine every PHP script ever written. What you have is nothing more than a small sample.
I, and others, will object to having to run any sort of conversion scripts just because you personally don't like the "var" keyword. It does no harm, so there is no benefit to be had by taking it out. -- Tony Marstonit would take effort to take it out...Here's a simple PHP script which does this automatically: https://gist.github.com/colinodell/5fb5e5d474674f294a38 Because "public" is supported in 5.x and 7.x, programmers could run this script at any time before the 8.0 release (assuming this proposed RFC passes and the programmer wants their code to run on 8.0)....and amend the documentationI will happily make that change myself.while programmers expect new features to be added they do NOT expect old features to disappear. Once a piece of code has been written and has proved to work as designed it is expected to work with all future versions.I'm hoping that the automated upgrade script and advance warning would help mitigate that impact.