Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91607
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <9E.71.53667.88D41E65@pb1.pair.com>
To: internals@lists.php.net
References: <1F.91.55238.41F10D65@pb1.pair.com>   <FA.10.10408.29514D65@pb1.pair.com> <56D42CD3.6020602@gmail.com> <DB.E1.07778.3D165D65@pb1.pair.com> <56D57DF4.8000906@gmail.com> <56D5D2AD.6070805@gmail.com> <56D5DDA6.4080607@fleshgrinder.com> <40.73.36499.548B6D65@pb1.pair.com> <56D6BBD0.5010505@gmail.com> <56D73386.3000903@fleshgrinder.com> <86.68.21983.A2508D65@pb1.pair.com> <56D86C00.6000904@fleshgrinder.com> <12.FB.08749.AF759D65@pb1.pair.com> <56DAC26C.50304@fleshgrinder.com> <56DAE00F.2030203@lsces.co.uk> <56DAF480.7030508@fleshgrinder.com> <CAMPTd_B6VNQymDJo2MX03KrOWd1Mcfjg6gNY=GO1swxV8snrKQ@mail.gmail.com> <0B.E0.29316.019CBD65@pb1.pair.com> <56DBFDB5.1010806@fleshgrinder.com> <43.5B.29316.A864DD65@pb1.pair.com> <56DD64F5.5010503@gmail.com> <D7.70.03587.1B0AED65@pb1.pair.com> <56DEA829.5030903@gmail.com> <2D.96.15119.232FFD65@pb1.pair.com> <CAL0xaBF-cx+hijFD=YNiihhKknpxwo0JdO+oNRada=B0jyyz7A@mail.gmail.com>
In-Reply-To: <CAL0xaBF-cx+hijFD=YNiihhKknpxwo0JdO+oNRada=B0jyyz7A@mail.gmail.com>
Date: Thu, 10 Mar 2016 10:33:23 -0000
Lines: 1
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="UTF-8";
	reply-type=original
Content-Transfer-Encoding: 7bit
Importance: Normal
Subject: Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal
From: TonyMarston@hotmail.com ("Tony Marston")

"Arvids Godjuks"  wrote in message 
news:CAL0xaBF-cx+hijFD=YNiihhKknpxwo0JdO+oNRada=B0jyyz7A@mail.gmail.com...
>
>All languages are evolving, and part of that is removing old baggage, even
>if that baggage is harmful. Because ease of maintenance. When you have
>multiple ways to do a thing, that means that when you touch some part of
>it, you have to remember to update everything else. It's easy with
>functions/methods, because aliasing is essentially forwarding the call. But
>with the language grammar that means modifying the parser for the language
>in multiple places and not necessarily as a copy/paste of the changed 
>rules.
>The argument, that it's there for ages is not a good technical argument why
>not to remove it.
>
>And by the way, there is an actual case, that var can't cover, but
>public/private/protected does.
>You can't do this:
>class Blah {
>    var static $a = 0;
>}
>
>but this obviously works
>class Blah {
>    public static $a = 0;
>}
>
>So, "var" is not the same as "public", it's a subset of "public"
>functionality actually. And I just checked the docs -it's not mentioned in
>the docs anywhere.
>
>And this is precisely why with time you need to remove the old baggage and
>duplicate functionality.

I disagree. There is *NO* need to remove duplicate functionality. There is 
*NO* need to remove functionality just because it is old or unfashionable.

>We can give people ample time to update libraries,
>because removing "var" is not going to happen until PHP8 for sure, that's
>probably at least 5-7 years, and deprecation warnings are easy to deal 
>with.
>Yes. we need to keep BC in mind, but this particular issue is trivially
>easy to fix, even automated tools are provided, cleans up an inconsistency
>between var and public, frees up "var" keyword for future usage for more
>advanced concepts and just removes the duplication of functionality.
>BC for the sake of BC is just silly.

It does not matter how easy you think the fix is, it would still place a 
huge burden on the application developers before they could take advantage 
of any improvements in the new version.

-- 
Tony Marston