Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:91597 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 6604 invoked from network); 9 Mar 2016 18:56:35 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Mar 2016 18:56:35 -0000 Authentication-Results: pb1.pair.com smtp.mail=php@fleshgrinder.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=php@fleshgrinder.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 212.232.28.122 cause and error) X-PHP-List-Original-Sender: php@fleshgrinder.com X-Host-Fingerprint: 212.232.28.122 mx201.easyname.com Received: from [212.232.28.122] ([212.232.28.122:45069] helo=mx201.easyname.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 2E/89-53667-1E170E65 for ; Wed, 09 Mar 2016 13:56:34 -0500 Received: from cable-81-173-133-29.netcologne.de ([81.173.133.29] helo=[192.168.178.20]) by mx.easyname.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1adjHa-0008MI-QH for internals@lists.php.net; Wed, 09 Mar 2016 18:56:31 +0000 Reply-To: internals@lists.php.net References: <1F.91.55238.41F10D65@pb1.pair.com> <56D42CD3.6020602@gmail.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> <0B.E0.29316.019CBD65@pb1.pair.com> <56DBFDB5.1010806@fleshgrinder.com> <43.5B.29316.A864DD65@pb1.pair.com> <56DD64F5.5010503@gmail.com> <56DEA829.5030903@gmail.com> <2D.96.15119.232FFD65@pb1.pair.com> To: internals@lists.php.net Message-ID: <56E071CC.6010907@fleshgrinder.com> Date: Wed, 9 Mar 2016 19:56:12 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="L0TXh54XGEtelJPdqv8oiq79MPsTSURrl" Subject: Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal From: php@fleshgrinder.com (Fleshgrinder) --L0TXh54XGEtelJPdqv8oiq79MPsTSURrl Content-Type: multipart/mixed; boundary="oCehMJAIeLVpnUH5E6GtI3d3guB8peSdn" From: Fleshgrinder Reply-To: internals@lists.php.net To: internals@lists.php.net Message-ID: <56E071CC.6010907@fleshgrinder.com> Subject: Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal References: <1F.91.55238.41F10D65@pb1.pair.com> <56D42CD3.6020602@gmail.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> <0B.E0.29316.019CBD65@pb1.pair.com> <56DBFDB5.1010806@fleshgrinder.com> <43.5B.29316.A864DD65@pb1.pair.com> <56DD64F5.5010503@gmail.com> <56DEA829.5030903@gmail.com> <2D.96.15119.232FFD65@pb1.pair.com> In-Reply-To: --oCehMJAIeLVpnUH5E6GtI3d3guB8peSdn Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable @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 i= t. On 3/9/2016 11:12 AM, Arvids Godjuks wrote: > All languages are evolving, and part of that is removing old baggage, e= ven > 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 o= f > 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 langu= age > in multiple places and not necessarily as a copy/paste of the changed r= ules. > The argument, that it's there for ages is not a good technical argument= why > not to remove it. >=20 > 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 =3D 0; > } >=20 > but this obviously works > class Blah { > public static $a =3D 0; > } >=20 > 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. >=20 > 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 librar= ies, > 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 inconsiste= ncy > between var and public, frees up "var" keyword for future usage for mor= e > advanced concepts and just removes the duplication of functionality. > BC for the sake of BC is just silly. >=20 > Arvids. >=20 :) --=20 Richard "Fleshgrinder" Fussenegger --oCehMJAIeLVpnUH5E6GtI3d3guB8peSdn-- --L0TXh54XGEtelJPdqv8oiq79MPsTSURrl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJW4HHVAAoJEOKkKcqFPVVr1kcP/A8rdVuNqoDWNrveL5gwwVJo nibx8ezQQOjOUCgSeQsUYc3uqry5hVfB33vsQs6Abtdx8/RtbJQDiR3m2NHnbnts fjYmp/OrEROiZMl3I3gwyZhId2Sc5Y5YPIbI2aApFxgPxYbx9z5StWOZSlZ+b7nl hqWgGVI2YGYMZ0FOU58xdreYv9afy2PHidK0SS65GDm7H668EO4n3aHPLQXkr3Zm Z2sF0LHPo7HsXMot7TnxBqZ30A7DXuEr1LRcsJ9YdNbP2X+NATuVUxq9D9tihIw6 Euytoj5d/3jk+R7TLK3+63E5q+p2ZECQ+LnDCwrIFvywHFfGUSW1aXp4HNoaVVMj NaMw0PE48nUce2ZqqqJ9ULcsCGiWPlOrjy05NQbme4ny8RbCr8c710BAkOjtWqDt c7Oa6IBbLMx8Z/8FzF6TusqB+dFYmw1flx2zvkkshT/ApoNy+cBZOsTPjK0+gM8b zC7EcSlcYRXQF3K9AY3Qz1WvQmxECXzJOb4YXHxY+rDvVSE0VM/o09JO4L13twJ2 eS7j/wsGC6vmhVTUC5A/7Q0n+qSfgrx4EoqvlamlE4znnoTroZZwqM7PCPsRIK3g KQ1+efsuQreijXusudyHKEZ6DNbsUThTfmI08hbDd40ciWIkEwXC+EtcXF2fXo5i AMTDd748EHvhujBxWsiH =GwKs -----END PGP SIGNATURE----- --L0TXh54XGEtelJPdqv8oiq79MPsTSURrl--