Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93854
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.49 as permitted sender)
To: internals@lists.php.net
References: <BY2PR0201MB178408B05E7A793C6470C7A9BF5C0@BY2PR0201MB1784.namprd02.prod.outlook.com>
 <ab92480e-2890-f240-b758-9f6d1113853b@gmail.com>
 <7d8183f5-4bea-d59f-79a6-7bde423854fc@gmx.de>
Message-ID: <8c880802-fad9-fc0b-be4c-96fb6add5bcd@gmail.com>
Date: Thu, 9 Jun 2016 14:54:17 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <7d8183f5-4bea-d59f-79a6-7bde423854fc@gmx.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] [VOTE] Replace "Missing argument" warning
 with"Too few arguments" exception
From: rowan.collins@gmail.com (Rowan Collins)

Apologies if this ends up as a duplicate. The list server seems to be, 
or have been, down, so trying to re-send and see what happens.


On 06/06/2016 14:38, Christoph Becker wrote:
> In my opinion it would be good to more explicitly clarify what
> constitutes an unacceptable BC break.  Bug fixes are allowed, but even
> those sometimes cause a BC break (as a programmer may rely on the buggy
> behavior).

Indeed, there is the famous xkcd cartoon highlighting that every change 
breaks somebody's expectations, and there is sometimes a grey area 
between clear bugs and unintended behaviour that is nonetheless unwise 
to change. There are also times when breaking compatibility is justified 
because the cost of doing so is low - e.g. the behaviour being changed 
is a rare edge case; or because the cost of *not* changing is high - 
e.g. fixing a major security flaw.

I think a case could be made for this change falling into the "cost of 
change is low" category, but am disappointed that the RFC itself makes 
no such case, and nor did there seem to be much engagement when it was 
raised on the pre-vote thread.

I'm also not convinced that such a justification would be in the spirit 
of the release process RFC. If the intent of the "no BC breaks in minor 
releases" policy is to make upgrades smoother, then producing fatal 
errors on code that previously ran without error seems like exactly what 
we should be avoiding.

I know that people SHOULD be fixing these incidences where they are 
producing Warnings currently, but that doesn't mean we can assume that 
they DO. This change has the same kind of implications as the removal of 
call-time pass-by-reference in 5.4, and I thought that was exactly what 
we didn't want to repeat.


Frankly, if this passes, as it currently looks set to do, I think the BC 
policy in the Release Process RFC should be officially abandoned or 
rewritten, because we will no longer be able to tell users "if it runs 
under 7.0, it will run under 7.1".

Regards,
-- 
Rowan Collins
[IMSoP]