@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
signature.asc
Description: OpenPGP digital signature
