Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91600
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <56E071CC.6010907@fleshgrinder.com>
References: <1F.91.55238.41F10D65@pb1.pair.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>
	<CAL0xaBF-cx+hijFD=YNiihhKknpxwo0JdO+oNRada=B0jyyz7A@mail.gmail.com>
	<56E071CC.6010907@fleshgrinder.com>
Date: Wed, 9 Mar 2016 15:53:04 -0500
Message-ID: <CAFGtT7a_cPru2GSaFymGBP9T0ikBW8GFUdAEVgdTKSPUNn1xqQ@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=001a11406aae6754d1052da3e294
Subject: Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal
From: geggleto@gmail.com (Glenn Eggleton)

--001a11406aae6754d1052da3e294
Content-Type: text/plain; charset=UTF-8

Hi list,

I think that removing it in any 7.x would be too soon. We should mark it as
future deprecation then remove it at a later date. While I don't come
across the use of var too much, it does still exist in code bases that are
quite old.

On Wed, Mar 9, 2016 at 1:56 PM, Fleshgrinder <php@fleshgrinder.com> wrote:

> @Tony Marston: I cannot reply anymore to you because you are
> discrediting yourself with every mail you send and I do not want to
> contribute to this any further; I might reply again if you write
> something that is actually contributing to this discussion. In the
> meantime: read what Rowan Collins wrote. :)
>
> On 3/8/2016 11:51 PM, Walter Parker wrote:
> > If this cleanup is such a good idea, why did it take 12 years for
> > someone to suggest it. Why wasn't var removed years ago? What is the
> > sudden urgency to remove it now?
> >
>
> It was already emitting an E_STRICT in the past but that was removed
> again. I cannot tell why there is no policy regarding such topics but
> now it just came up. Also note, removal could have happened with PHP 7
> the earliest. This chance was missed due to more important topics.
>
> On 3/8/2016 11:51 PM, Walter Parker wrote:
> > Have programmer become more confused? This alias does not appear to
> > have been an issue for the last 12 years.
> >
>
> Nope, of course not. That was just one of several arguments why the
> removal should happen in the future.
>
> On 3/8/2016 11:51 PM, Walter Parker wrote:
> > What has changed? Are we on a cusp of the paradigm change (the type
> > that happens when the old folk have gone away, so the younger folk
> > can get their way because they now have the numbers)?
> >
>
> Maybe, or maybe some people simply take the major criticism of their
> favorite language seriously and see it as constructive input to improve it.
>
> On 3/9/2016 11:12 AM, Arvids Godjuks wrote:
> > 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.
> >
>
> :)
>
> --
> Richard "Fleshgrinder" Fussenegger
>
>

--001a11406aae6754d1052da3e294--