Re: [RFC Proposal] var keyword deprecation/removal

Good morning Internals! I am strongly AGAINST the removal of the var keyword from PHP syntax. Though in general it's an alias of public (or it simply ‘acts’ as the public modifier), I see a difference in its _semantics_. While the public modifier states anyone can change the property, var is useful for marking internal properties which must be public, but should not be manipulated by simply anybody e.g. in the case of dependency injection: <?php class HomepagePresenter extends Nette\Application\UI\Presenter { /** @var Model\FooService @inject */ var $fooService; public function renderFooExample() { // now you can use $this->fooService thanks to DI container } } ?> This idea comes to me from using the Nette Framework, which handles DI automatically and this way -- using var -- one can semantically mark, which are the internally @inject'ed properties and differ them from the public ones. On 26 February 2016 at 15:16, Tony Marston <TonyMarston@hotmail.com> wrote: > 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: >> >>> 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). > > > 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. > >> 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. > >>> it 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 documentation >> >> >> >> I 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. > > > 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 Marston > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > Thanks! -- Cheers, Kubis