Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91612
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.42 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> <56E0025C.5040202@gmail.com>
 <45.F1.53667.4AE41E65@pb1.pair.com>
Message-ID: <56E15C99.5040101@gmail.com>
Date: Thu, 10 Mar 2016 11:38:01 +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: <45.F1.53667.4AE41E65@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 10/03/2016 10:38:
> "Rowan Collins"  wrote in message news:56E0025C.5040202@gmail.com...
>> 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.
>

OK, so you've listed two reasons that should be accepted, and one that 
shouldn't (which is something of a straw man, because I don't think 
anyone would directly defend a proposal as "fashionable"). But that's 
still not a full definition, as you acknowledge with your "such as".

So, remembering that a lot of this is YOUR opinion, and other people are 
perfectly entitled to disagree with you, I would still be interested if 
you could come up with a test that you would like applied for what is a 
"valid reason" for a BC break. We can't really have a policy of "ask 
Tony Marston if it's OK", so the only practical way forward is for us to 
come up with such a test.

Scenarios to consider include: creating a new function (someone might 
have created a custom function with that name); functionality that 
depended on deprecated or unmaintained third-party code; replacing a 
scenario that currently generates an error with working code.

Regards,
-- 
Rowan Collins
[IMSoP]