Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91570
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <2D.96.15119.232FFD65@pb1.pair.com>
References: <1F.91.55238.41F10D65@pb1.pair.com> <CAHvhOfhYpnjkSjuo09TY7irhgW5UxNYZcWqtAr0iCcUAqJUgqw@mail.gmail.com>
 <CAKnqCEY7art1GUWG=Pm0wyPGQmYp0Dq8oxdohgBkSGq+O_BTZw@mail.gmail.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>
Date: Wed, 9 Mar 2016 12:12:06 +0200
Message-ID: <CAL0xaBF-cx+hijFD=YNiihhKknpxwo0JdO+oNRada=B0jyyz7A@mail.gmail.com>
To: Tony Marston <TonyMarston@hotmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1140207e475803052d9aefac
Subject: Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--001a1140207e475803052d9aefac
Content-Type: text/plain; charset=UTF-8

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. 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.

Arvids.

--001a1140207e475803052d9aefac--