Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:91508 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 89861 invoked from network); 5 Mar 2016 11:27:02 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Mar 2016 11:27:02 -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:37384] helo=mx201.easyname.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 92/21-08669-482CAD65 for ; Sat, 05 Mar 2016 06:27:01 -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 1acAML-00062B-CL for internals@lists.php.net; Sat, 05 Mar 2016 11:26:57 +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> To: internals@lists.php.net Message-ID: <56DAC26C.50304@fleshgrinder.com> Date: Sat, 5 Mar 2016 12:26:36 +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: <12.FB.08749.AF759D65@pb1.pair.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rHDxej2rl0EaCVMj53xxMm2tEiQOu5OfL" Subject: Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal From: php@fleshgrinder.com (Fleshgrinder) --rHDxej2rl0EaCVMj53xxMm2tEiQOu5OfL Content-Type: multipart/mixed; boundary="UGbQMTsko55kLnGsasUgKoNXWjp5QGQAj" From: Fleshgrinder Reply-To: internals@lists.php.net To: internals@lists.php.net Message-ID: <56DAC26C.50304@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> In-Reply-To: <12.FB.08749.AF759D65@pb1.pair.com> --UGbQMTsko55kLnGsasUgKoNXWjp5QGQAj Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/4/2016 10:39 AM, Tony Marston wrote: > wrote in message news:56D86C00.6000904@fleshgrinder.com... >> >> 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 = the >>> (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 w= as >> added by popular demand >=20 > Really? Exactly how many of the millions of PHP developers out there > voted for this change? I was not part of the decision back then, however, it was how I received the addition of the feature. >> 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. >=20 > Is it actually a "problem"? How many books and articles on PHP > programming are out there which use the "old" syntax? How much confusio= n > would it cause if the "old" and well known syntax were to be dropped? > How many applications would suddenly stop working? How much effort woul= d > be required in userland to fix this state of affairs? How many swear > words would these userland developers have for the language developers?= > There are NO sideeffects of leaving aliases in the language. It would > take NO effort to leave them in, but it would take effort to take them > out which includes updating immense volumes of documentation. The only > "problem" is that it offends the delicate sensibilities of a few > "purist" developers who cannot understand the difference between > improving the language and breaking it. The argument in regards to books and articles is imho irrelevant. Nobody learns Java 8 with a Java 2 book; nor do you learn PHP 8 with a PHP 4 book. This is just silly. The upgrade path is important and not the fact that some 15+ year old applications might not work anymore. Rowan Collins makes a much better case here with his arguments instead of nagging at the stale argument of "we need to support every line of (bad) code out there". PHP being a mess is still one of the most quoted arguments against PHP! > Only if it results in an actual and measurable improvement. Changes for= > "purity" or "consistency" do NOT fall into this category. This is your believe and you know that many people disagrees with you on this; you just commented on the "[RFC] Deprecations for PHP 7.1" thread and we have much more of those RFCs and threads. --=20 Richard "Fleshgrinder" Fussenegger --UGbQMTsko55kLnGsasUgKoNXWjp5QGQAj-- --rHDxej2rl0EaCVMj53xxMm2tEiQOu5OfL 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 iQIcBAEBCAAGBQJW2sJvAAoJEOKkKcqFPVVro+kP/jv7sQQ+6Q7wUJBpVTqsCBE/ 0nHDizKxWjgKTkBGUam9ErQlUhzrMTronZPZbSnem9RS/si3regbgskqxnXvx+LL +fx5GCq3h6GVVe7/etiWZYXLmeRvZqpt1RGKjbHBN/PG2iR11MrfUvQC0iPhMhnj N57GG3Z9Omr/W79kxTQp7u3wyoJ8OydU2B4lMKwvwFkTR7GaD9MwIkCZTCC5gN81 EMoS80LRgd0YK05nxfCYzbpI59vjj/yBoeMJ10uh4djKnWdU9OI3U/+yhrkxfAlb AVK7VsCWC+uaok4vRqnVcQbdSpV1CtXcxYP27W/4oYnyoBK12KSNK4LHJrx3NLJ3 HHKtix9BynArZSdL113PiWMi0+k9SzMltPzXO6M9bj2sEiulm3LlN9AM3xt+/0lF konBH96OLpUxClC/OUc3NDFiCi2NKirsVf13ZZlA2FtOVGzu5DfeftM0MosMhDgt tga2FvMsjue3YuT7gPal1qyR3SdB7FfOgGExkh7EkNT7UinAo8EJN8rBCsDky1U1 0z6okcHiJX/Aj1jFP9AfdHYr8qJ1T2lcrEmw1cieLysrkg0kna7zFv+Z+XgAtxfx ZFYvPbW1ducDil3DLCodUwl22Vo0hZoDrZ4mbgxg+yLuoe5EXHHO4XFL0/g/ENAc y8GnAmEqDwLVVtGXMMRz =wo94 -----END PGP SIGNATURE----- --rHDxej2rl0EaCVMj53xxMm2tEiQOu5OfL--