Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93924
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)
References: <6c03dafd-093a-0087-6312-96fede93c5f0@gmail.com>
 <CAF+90c9FazFL9Do6xFKQmYR58QTd7cKePpf1LK7z74N9VkRB2A@mail.gmail.com>
 <027a527e-0920-9e57-b2cc-60fcbfedb84e@gmail.com>
 <CAF+90c8EKWBWvt1LzbyEYuL4L2GFQ6VQDiHzwND28x6Eca0XHw@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Message-ID: <03174fa7-a793-6792-1e04-20c88af55155@gmail.com>
Date: Sun, 12 Jun 2016 23:23:17 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <CAF+90c8EKWBWvt1LzbyEYuL4L2GFQ6VQDiHzwND28x6Eca0XHw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy
 enforceable?
From: rowan.collins@gmail.com (Rowan Collins)

On 12/06/2016 20:55, Nikita Popov wrote:
> In that it is similar to the RFC on introducing warnings for invalid 
> numeric strings in arithmetic operations. Sure, that one introduces 
> only a notice while this one throws an exception. Most people probably 
> don't share this opinion, but I think there's actually very little 
> difference between the two for a professional codebase, which 
> (obviously ^^) has a zero notice/warning policy. In either case it's 
> something that must be fixed. (This means that the breakage, if 
> defined as "work required for a deployable upgrade", is probably much 
> much higher for the invalid arithmetic RFC, even though the breakage 
> as in "how badly is the code broken if I do nothing" is smaller.)

OK, that at least is a specific line of reasoning. I don't agree with 
it, but I can respect its logic.

For the record, I disagree because introducing an error changes program 
flow, whereas introducing a warning does not (except if there is some 
handler indiscriminately promoting warnings to errors, I guess, but I'm 
not aware that that is common practice). Even with a "zero 
notice/warning policy", it is possible to at least test your application 
without fixing a new warning; with a new error, you have to fix the 
problem before doing anything else. Or, more likely, you postpone 
adoption of the new version, which is surely something we wanted to avoid.


> c) If you subscribe to defensive programming, the current behavior 
> implies that you should actually be adding an assert(isset($param)) 
> for each parameter to the start of your function, to ensure that your 
> **required** parameters are really passed. WTF? If I can't rely on 
> required parameters being required in this programming language, what 
> can I rely on at all? I'm willing to accept a small degree of BC 
> breakage to get rid of such nonsense.

Unfortunately, this is still the case after this change: any parameter 
which can currently be omitted will also accept nulls. The only way of 
marking a parameter mandatory is to give it a type hint. So as the 
author of a function, this change makes absolutely no difference to your 
code; if you want a parameter to be mandatory, the solution in 7.1 as in 
7.0 is to add a type hint. As the user of a function, it increases the 
visibility of an existing warning; since you claim any "professional 
codebase" will have a zero notice/warning policy anyway, this change 
will make no difference there either.

Regards,

-- 
Rowan Collins
[IMSoP]