Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Re: [RFC Proposal] var keyword deprecation/removal »

Re: [RFC Proposal] var keyword deprecation/removal

php.internals

Tony Marston

10 years ago
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

Jakub Kubíček

10 years ago
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

James Titcumb

10 years ago
On 28 Feb 2016 06:18, "Jakub Kubíček" <kelerest123@gmail.com> wrote:
> > 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
If it's public, it will be modified by someone. This isn't an intended semantic meaning of `var`, and simply saying "don't modify this please" is never going to be enough. Make them private, protected or public and make your intent clear, because for anyone unfamiliar with this design will simply translate `var` to mean `public`, and use it as such.

Tony Marston

10 years ago
"James Titcumb" wrote in message news:CAKnqCEY7art1GUWG=Pm0wyPGQmYp0Dq8oxdohgBkSGq+O_BTZw@mail.gmail.com...
> >On 28 Feb 2016 06:18, "Jakub Kubícek" <kelerest123@gmail.com> wrote: >> >> 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 > >If it's public, it will be modified by someone.
Incorrect. It *may* be modified, but surely any invalid modifications will be detected in the testing phase?
> This isn't an intended >semantic meaning of `var`, and simply saying "don't modify this please" is >never going to be enough. Make them private, protected or public and make >your intent clear, because for anyone unfamiliar with this design will >simply translate `var` to mean `public`, and use it as such.
If "var" is automatically translated into "public", and has been since PHP 5 emerged, and has been documented to behave in this way, then what does it cost to leave it that way? Answer: NOTHING!
-- Tony Marston

Rowan Collins

10 years ago
Tony Marston wrote on 29/02/2016 09:55:
> "James Titcumb" wrote in message > news:CAKnqCEY7art1GUWG=Pm0wyPGQmYp0Dq8oxdohgBkSGq+O_BTZw@mail.gmail.com... > >> >> On 28 Feb 2016 06:18, "Jakub Kubícek" <kelerest123@gmail.com> wrote: >>> >>> 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 >> >> If it's public, it will be modified by someone. > > Incorrect. It *may* be modified, but surely any invalid modifications > will be detected in the testing phase?
Detected by whom? Using what tool? I'm not aware of any generic way of logging all access to particular properties, nor quite what "invalid modifications" mean in this labelling scheme. Maybe it would be detected during *review*? Apologies if that's what you meant and the distinction sounds pedantic. A better way to mark this kind of distinction is using PHPDoc annotations, which can be made readable by both humans and tools. For instance, PHPStorm will cross through any uses of a property marked "@internal"; I wouldn't be surprised if other IDEs and tools can pick this up as well. In this case, you could just use the fact that the property is labelled "@inject" to mark the distinction, and you'd be no worse off in terms of tooling support than you are now (i.e. IDEs will not come with this interpretation of "var" baked in anyway). Regards,
-- Rowan Collins [IMSoP]

Tony Marston

10 years ago
"Rowan Collins" wrote in message news:56D42CD3.6020602@gmail.com...
> >Tony Marston wrote on 29/02/2016 09:55: >> "James Titcumb" wrote in message >> news:CAKnqCEY7art1GUWG=Pm0wyPGQmYp0Dq8oxdohgBkSGq+O_BTZw@mail.gmail.com... >> >>> >>> On 28 Feb 2016 06:18, "Jakub Kubícek" <kelerest123@gmail.com> wrote: >>>> >>>> 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 >>> >>> If it's public, it will be modified by someone. >> >> Incorrect. It *may* be modified, but surely any invalid modifications >> will be detected in the testing phase? > >Detected by whom? Using what tool?
If changing a variable directly instead of using a setter does not produce an error that can be detected in your testing, whether that testing is automated or manual, then is there actually an error? If doing something does not cause a problem there there is no problem that needs fixing. Preventing something from happening which does not cause an error even if it did happen seems like wasted effort to me.
-- Tony Marston

Rowan Collins

10 years ago
Tony Marston wrote on 01/03/2016 09:32:
> "Rowan Collins" wrote in message news:56D42CD3.6020602@gmail.com... >> >> Tony Marston wrote on 29/02/2016 09:55: >>> "James Titcumb" wrote in message >>> news:CAKnqCEY7art1GUWG=Pm0wyPGQmYp0Dq8oxdohgBkSGq+O_BTZw@mail.gmail.com... >>> >>> >>> Incorrect. It *may* be modified, but surely any invalid modifications >>> will be detected in the testing phase? >> >> Detected by whom? Using what tool? > > If changing a variable directly instead of using a setter does not > produce an error that can be detected in your testing, whether that > testing is automated or manual, then is there actually an error? If > doing something does not cause a problem there there is no problem > that needs fixing. Preventing something from happening which does not > cause an error even if it did happen seems like wasted effort to me. >
Firstly, no test suite can ever truly cover 100% of scenarios that the live application will encounter, so the idea that a bug doesn't exist until it causes an error is asking for trouble. You want to catch mistakes as early as possible, and that is exactly what member visibility is there for in the first place - to stop you in your tracks if you try to access something that was supposed to be internal. Secondly, violating visibility may have repercussions outside actual errors. Consider something relying on accessing an "internal" property and writing dozens of lines of code assuming it is of a particular type. Then consider that the maintainer of the module which declared it refactors and removes, renames, or changes the type of that property, confident that they are safe to do so because it was for internal use only. The result is much more wasted effort than keeping an eye out that you're not violating visibility in the first place. Regards,
-- Rowan Collins [IMSoP]

Rowan Collins

10 years ago
Rowan Collins wrote on 01/03/2016 11:33:
> > Secondly, violating visibility may have repercussions outside actual > errors.
Incidentally, PHP itself encountered this a few years ago, where a release of libxml2 changed internal behaviour that was being relied on for a hack. The result was that entities like &gt; started silently disappearing from everyone's parsed XML if they compiled PHP against the new library. See https://bugs.php.net/bug.php?id=45996 and http://thread.gmane.org/gmane.comp.gnome.lib.xml.general/14610 Regards,
-- Rowan Collins [IMSoP]

Fleshgrinder

10 years ago
On 3/1/2016 6:34 PM, Rowan Collins wrote:
> Rowan Collins wrote on 01/03/2016 11:33: >> >> Secondly, violating visibility may have repercussions outside actual >> errors. > > > Incidentally, PHP itself encountered this a few years ago, where a > release of libxml2 changed internal behaviour that was being relied on > for a hack. The result was that entities like &gt; started silently > disappearing from everyone's parsed XML if they compiled PHP against the > new library. See https://bugs.php.net/bug.php?id=45996 and > http://thread.gmane.org/gmane.comp.gnome.lib.xml.general/14610 > > Regards,
The misuse of "var" as it was explained is reason alone to take action.
-- Richard "Fleshgrinder" Fussenegger

Tony Marston

10 years ago
wrote in message news:56D5DDA6.4080607@fleshgrinder.com...
> >On 3/1/2016 6:34 PM, Rowan Collins wrote: >> Rowan Collins wrote on 01/03/2016 11:33: >>> >>> Secondly, violating visibility may have repercussions outside actual >>> errors. >> >> >> Incidentally, PHP itself encountered this a few years ago, where a >> release of libxml2 changed internal behaviour that was being relied on >> for a hack. The result was that entities like &gt; started silently >> disappearing from everyone's parsed XML if they compiled PHP against the >> new library. See https://bugs.php.net/bug.php?id=45996 and >> http://thread.gmane.org/gmane.comp.gnome.lib.xml.general/14610 >> >> Regards, > >The misuse of "var" as it was explained is reason alone to take action.
Just because one developer out of millions made a mistake is no reason to punish those millions. If "var" can be abused then "public" can be abused in the same way, so surely the only way to avoid the possibility of ANY abuse whatsoever would be to remove "public" as well as "var".
-- Tony Marston

Jakub Kubíček

10 years ago
On 29 February 2016 at 15:25, Tony Marston <TonyMarston@hotmail.com> wrote:
> If "var" is automatically translated into "public", and has been since PHP 5 > emerged, and has been documented to behave in this way, then what does it > cost to leave it that way? Answer: NOTHING!
Yeah. This is actually very true.
-- Cheers, Kubis