Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93273
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.45 as permitted sender)
To: internals@lists.php.net
References: <CAFMT4NqTm6z-QYt2SOUMWtcDv+dzFtBEMcKRfcXE-DP0SpzkOQ@mail.gmail.com>
 <CAFMT4NoZtTDZmift7RVn9omvfHJFF1c0pnN8N0rBR=sh42q+Nw@mail.gmail.com>
 <573232DB.8030209@lsces.co.uk>
 <CAFMT4NrtkD97tKsfawxUyVR1smSsbKCj-i=SWgRiemp_PWtzkg@mail.gmail.com>
 <573308EC.70502@lsces.co.uk>
 <CANaX5nekTU5n-_Lx98oXhP1mE10R6jfoaaioLux3Cz7nXNDW6Q@mail.gmail.com>
 <57346ABE.1070509@lsces.co.uk>
Message-ID: <6dabc30a-7b4b-d71c-5a64-4005fd622a2e@gmail.com>
Date: Thu, 12 May 2016 13:38:47 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <57346ABE.1070509@lsces.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [RFC][VOTE] Nullable Types
From: rowan.collins@gmail.com (Rowan Collins)

On 12/05/2016 12:36, Lester Caine wrote:
> On 12/05/16 11:21, Davey Shafik wrote:
>> E.g. the behavior of passing executing with a null value for the
>> argument is something you should be consciously making a decision on,
>> and passing in null explicitly.
>
> I was actually getting the logic wrong... the problem with this proposal
> is that I HAVE to add the '?' for many of my libraries to continue to
> work simply because they do handle the null case. So what was a working
> system is broken by this change.
>

As I understand it, no existing code will change behaviour under this 
proposal. It merely adds an extra feature which libraries *can* use. 
What's more, it's a feature which makes those libraries *less strict*, 
not more.

Existing code:

function something(Bar $bar) {}
something(new Bar); // OK
something(); // Error: Missing required parameter
something(null); // Error: Parameter is not of required type

function something_else(Bar $bar = null) {}
something_else(new Bar); // OK
something_else(); // OK
something_else(null); // OK

None of this behaviour is going to change, no existing code will break.


Now let's say the author of the something function decides to use the 
new nullable type hint:

function something(?Bar $bar) {}
something(new Bar); // OK
something(); // Error: Missing required parameter
something(null); // OK

None of your code will be calling something(null) yet, because it was 
previously an error. So you now have an *extra* way of calling the 
function, but you don't need to change any existing usages.


The only breaking change would be if the author of the something_else 
function decided to make the argument mandatory but nullable, so that 
"something_else()" would be an error, but "something_else(null)" 
wouldn't be. But that's just the same as if they made the argument 
completely mandatory - it's a breaking change in the library, not 
something the language change has caused to happen.

Regards,
-- 
Rowan Collins
[IMSoP]