Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91447
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1F.91.55238.41F10D65@pb1.pair.com>
References: <1F.91.55238.41F10D65@pb1.pair.com>
Date: Sun, 28 Feb 2016 11:48:34 +0530
Message-ID: <CAHvhOfhYpnjkSjuo09TY7irhgW5UxNYZcWqtAr0iCcUAqJUgqw@mail.gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal
From: kelerest123@gmail.com (=?UTF-8?B?SmFrdWIgS3Viw63EjWVr?=)

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
=E2=80=98acts=E2=80=99 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 ho=
w
>>> "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 dependenci=
es.
>> Adjusting these packages would drastically lower overall usage across th=
e
>> ecosystem.  And because "var" is simply an alias for "public", making th=
at
>> 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 t=
o
>> get more-accurate figures.
>
>
> The only way to obtain what could be called "accurate" figures would be t=
o
> 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 progra=
mmer
>> 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 ol=
d
>>> 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 script=
s
> 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!

--=20
Cheers,
Kubis