Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:91608 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 67739 invoked from network); 10 Mar 2016 10:38:29 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Mar 2016 10:38:29 -0000 X-Host-Fingerprint: 80.177.120.119 marston-home.demon.co.uk Received: from [80.177.120.119] ([80.177.120.119:22089] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 45/F1-53667-4AE41E65 for ; Thu, 10 Mar 2016 05:38:29 -0500 Message-ID: <45.F1.53667.4AE41E65@pb1.pair.com> 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> <56dd744b.8157620a.cddfc.74ed@mx.google.com> <56DDEF7B.6080309@fleshgrinder.com> <56DECE15.703@lsces.co.uk> <56DF1750.6050503@lsces.co.uk> <56DF3DFB.10007@fleshgrinder.com> <56E0025C.5040202@gmail.com> In-Reply-To: <56E0025C.5040202@gmail.com> Date: Thu, 10 Mar 2016 10:38:08 -0000 Lines: 1 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Newsreader: Microsoft Windows Live Mail 16.4.3564.1216 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3564.1216 X-Posted-By: 80.177.120.119 Subject: Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal From: TonyMarston@hotmail.com ("Tony Marston") "Rowan Collins" wrote in message news:56E0025C.5040202@gmail.com... > >Tony Marston wrote on 09/03/2016 10:31: >> As a developer who went through several COBOL upgrades I can attest to >> the fact that BC breaks were extremely rare and only for a good reason. >> My code was never affected simply because I never used any of the dodgy >> features (such as ALTER ... GO TO ...) which were removed. > >... > >> I personally started with UNIFACE v5 and move through v6 and v7 without >> any BC breaks. How was this possible? Because I never used those features >> which caused problems and were later removed. > >OK, so it was not that there were no BC breaks, just that they happened not >to affect you, because you weren't using the removed features. So if, to >give an example that was recently discussed, you never used PHP's >create_function() function, you would be able to upgrade to a version that >removed it without any changes. Clearly, this is not the same thing as >"never break BC". > >This leaves us back with a decision about *which* BC breaks are acceptable, >discussion of which includes how many people use the feature, how it will >affect them, and what the benefits are in the particular case. No BC breaks are acceptable unless it is for a valid reason, such as a security issue or a performance issue. Changes in fashion are NOT a good reason. -- Tony Marston