Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:91487 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 30217 invoked from network); 3 Mar 2016 16:53:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Mar 2016 16:53:47 -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.126 cause and error) X-PHP-List-Original-Sender: php@fleshgrinder.com X-Host-Fingerprint: 212.232.28.126 mx205.easyname.com Received: from [212.232.28.126] ([212.232.28.126:49414] helo=mx205.easyname.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 99/D3-08749-81C68D65 for ; Thu, 03 Mar 2016 11:53:45 -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 1abWVR-0008Gj-NK for internals@lists.php.net; Thu, 03 Mar 2016 16:53:42 +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> To: internals@lists.php.net Message-ID: <56D86C00.6000904@fleshgrinder.com> Date: Thu, 3 Mar 2016 17:53:20 +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: <86.68.21983.A2508D65@pb1.pair.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VcLpdsB6m97VSRgMld3FJ9uVs5x4pdt3B" Subject: Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal From: php@fleshgrinder.com (Fleshgrinder) --VcLpdsB6m97VSRgMld3FJ9uVs5x4pdt3B Content-Type: multipart/mixed; boundary="gEBKExXaWSTfxngwIK84mx0U4f3vcEsOg" From: Fleshgrinder Reply-To: internals@lists.php.net To: internals@lists.php.net Message-ID: <56D86C00.6000904@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> In-Reply-To: <86.68.21983.A2508D65@pb1.pair.com> --gEBKExXaWSTfxngwIK84mx0U4f3vcEsOg Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/3/2016 10:34 AM, Tony Marston wrote: > If you want to avoid such confusion over alias names then surely that > would be an argument against introducing aliases in the first place. In= > this case the short array syntax would never have been introduced as th= e > (only slightly longer) long array syntax had already existed since day = #1. No, that is not what one should conclude from it. Short array syntax was added by popular demand and hence for a very good reason. The fact that there are no plans regarding the old syntax and thus keeping the duplication indefinitely is the actual problem. Change for the sake of change is bad, no argument there. Change for the sake of progress is not and totally normal. On 3/3/2016 2:04 PM, Rowan Collins wrote: > I'm not sure what Lester had in mind, but in many cases legacy code > which used "var" should actually be updated to mark properties as > "protected" or "private" instead. Such properties are public only > because PHP4 had no other visibility, and explicitly marking them all > "public" simply masks the real job, which is assessing which > visibility each property should have. > > It occurs to me that if I saw "var", I would not think "that should be > public", but "that needs assessing for visibility". I do the same with > legacy code where methods are written as "function foo()" rather than > "public function foo()" - I check whether it should actually be > public, and also in that case whether it should be static. It seems as if this is not the issue for the people who are against removing the "var" keyword from PHP 8. They simply do not want to change their scripts at all. The described procedure is truly time consuming since it involves to check all usages everywhere as well. Simply changing from "var" or "public" to any other visibility is a brutal chang= e. --=20 Richard "Fleshgrinder" Fussenegger --gEBKExXaWSTfxngwIK84mx0U4f3vcEsOg-- --VcLpdsB6m97VSRgMld3FJ9uVs5x4pdt3B 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 iQIcBAEBCAAGBQJW2GwIAAoJEOKkKcqFPVVr9K8P/j0OKuaqW3s/+r3Epl1pT6r8 /RxWCpXdhZROIc+ejHaD7t42moqUX93HPj41mp+Cq41/HCEgqDDmRE9PQuqh86mK sE6/MVfu6VXo9JV0kx6va/Or96+1vZFDVgHEXQMPINYJuQaiYqEScZ3pFYb5eKtz Tdu2vE6MfSzAxToELU3orSN1xhFTzEmUjvIU5TwOOu4sB+mk14DsZ1MsAOuwVQvy VMEaJpt9GNx7HM7XTAd9NSLBk2yvMDuS/9qq2CqTJFMsDQYL5j/bAgwsO8q5VBs7 GKPuEA0gg0zrpFDoHNktFOZeBbyIvWpDJYEtu3X9mV5vdjAyvhCBqvquwXYXUG6v zFwpa1sZksW0pvgE5GwcRquUwZ033fjzlkUIZLKhl+hpz/MrkprjMtktmQ6Jt5gj PQqSwN9+TgxdbUA4jRc+vtI6GnuvKXlyXPXSPGvwFRqfp22Z/FxkbzkziHJkV/o6 q0nRSSJNgsRZ6N+z8OaSfXuv6dWV9PTilhE0Bgqf7YF8jom1mDU0AwWzXUtBoXh3 IVWhpZckFBWuTDkKXmHuoxZJnELrKA1hmnw43y6L/2ziWJ9uwKMobwQGW87lxtbe +Kcvb4BAf8ceWKE9yIxVaiV7NntE5xLGEBtXzRm+UYVOf2HaZKAyGcwtyqEpHIji nYTyEXtz3pfI2bKe7Jrw =Yc7x -----END PGP SIGNATURE----- --VcLpdsB6m97VSRgMld3FJ9uVs5x4pdt3B--