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 <p...@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
>
>
