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 <tonymars...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
