Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91575
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.50 as permitted sender)
To: internals@lists.php.net
References: <1F.91.55238.41F10D65@pb1.pair.com>
 <CAHvhOfhYpnjkSjuo09TY7irhgW5UxNYZcWqtAr0iCcUAqJUgqw@mail.gmail.com>
 <CAKnqCEY7art1GUWG=Pm0wyPGQmYp0Dq8oxdohgBkSGq+O_BTZw@mail.gmail.com>
 <FA.10.10408.29514D65@pb1.pair.com> <56D42CD3.6020602@gmail.com>
 <DB.E1.07778.3D165D65@pb1.pair.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> <E8.41.03587.B85AED65@pb1.pair.com>
 <56DECE15.703@lsces.co.uk>
 <CAH=AbGJAnYK1Vra+7mU=Ldcb+9Tp6+qbT9yaVzX60GJ=YJsTnA@mail.gmail.com>
 <56DF1750.6050503@lsces.co.uk> <56DF3DFB.10007@fleshgrinder.com>
 <A7.98.15119.6ABFFD65@pb1.pair.com>
Message-ID: <56E0025C.5040202@gmail.com>
Date: Wed, 9 Mar 2016 11:00:44 +0000
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: <A7.98.15119.6ABFFD65@pb1.pair.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal
From: rowan.collins@gmail.com (Rowan Collins)

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.

Now, I think it's safe to assume that the example of "var" is something 
that a lot of code will be using, and I have already said that, in this 
particular case, I don't think the benefits outweigh the costs. But I 
come to that conclusion not on the principle of "change nothing", but on 
the principle of weighing costs and benefits, which I am happy to delve 
into the details of on a case-by-case basis.

Regards,
-- 
Rowan Collins
[IMSoP]