Re: [RFC Proposal] var keyword deprecation/removal

@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

Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc