This is not a default value (i.e. you can use = null in middle of required
parameters), but defacto a nullable parameter type.
Default values should and will always be changeable between functions in an
inheritance tree.
And while it's a tiny BC break, one can very easily fix the function from
function (array $foo = []) { ... }
to
function (array $foo = null) { if (!$foo) { $foo = []; } ... }
Which satisfies all of todays and future code.
Thanks,
Bob
> Am 28.04.2016 um 20:34 schrieb Dmitry Stogov <[email protected]>:
>
> PHP method compatibility rules didn't take into account default values of
> arguments.
> Adding new rule is not just a bug fix, and breaks existing code.
>
> ________________________________________
> From: Bob Weinand <[email protected]>
> Sent: Thursday, April 28, 2016 9:12:54 PM
> To: Dmitry Stogov
> Cc: Anatol Belski; Joe Watkins; internals; Levi Morrison
> Subject: Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only
> return values
>
> Yeah,
> It's a BC break; hence I've accepted it being reverted from 7.0.
> I've only put the fix back in 7.1 thus.
>
> Or is it your opinion that we shall hold a formal RFC vote for a glaring bug?
> That sounds pretty much like a waste of everyones time to me. RFC votes IMO
> are for cases where we don't have clear consensus. Or is really anyone
> disputing this fix?
>
> Bob Weinand (iPhone)
>
>> Am 28.04.2016 um 19:59 schrieb Dmitry Stogov <[email protected]>:
>>
>> This is a "fix", that introduces BC break.
>> Even if I see a reason in this check, it's still a break.
>> If you remember, we voted for almost for every BC break during PHP-7.0
>> development.
>>
>>
>> ________________________________________
>> From: Bob Weinand <[email protected]>
>> Sent: Thursday, April 28, 2016 8:36:22 PM
>> To: Dmitry Stogov
>> Cc: Anatol Belski; Joe Watkins; internals; Levi Morrison
>> Subject: Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only
>> return values
>>
>>> Am 28.04.2016 um 18:28 schrieb Dmitry Stogov <[email protected]>:
>>>
>>> Hi,
>>>
>>> The BC break in PHP-7.0 was introduced by commit
>>> ee9a78a033696ff9546fb1dbfecd28f20477b511
>>>
>>> Author: Joe Watkins <[email protected]>
>>> Date: Mon Mar 28 11:54:25 2016 +0100
>>>
>>> Late, there were few more commits that changed and moved the problematic
>>> code.
>>>
>>> Anatol, I think we should revert this before 7.0.6 release.
>>>
>>> Thanks. Dmitry.
>>>
>>> ________________________________________
>>> From: [email protected] <[email protected]> on behalf of Levi
>>> Morrison <[email protected]>
>>> Sent: Thursday, April 28, 2016 18:40
>>> To: internals
>>> Cc: Dmitry Stogov; Tom Worster
>>> Subject: Request to withdraw RFC's for nullable types for only return values
>>>
>>> I have discovered through a [bug report][1] a case where having
>>> explicitly nullable parameters would be of value.
>>>
>>> <?php
>>>
>>> interface Foo {
>>> public function bar(array $baz = null);
>>> }
>>>
>>> class Hello implements Foo {
>>> public function bar(array $baz = array()) {}
>>> }
>>>
>>> ?>
>>>
>>> You can theoretically change the default value in a sub-type, but in
>>> this case moving away from the default value of null breaks because
>>> the subtype no longer permits null. It is important to realize that we
>>> previously *allowed* this behavior since PHP 5.1 but was fixed in
>>> 7.0.6.
>>>
>>> If instead we had nullable types separately from default values of
>>> null this could change to:
>>>
>>> <?php
>>>
>>> class Hello implements Foo {
>>> public function bar(array | null $baz = []) {}
>>> }
>>>
>>> ?>
>>>
>>> (or a short-form `?array $baz = []` if short-form passes)
>>>
>>> This preserves the ability to be null but changes the default value.
>>> Of course, there may be other code changes necessary to future-proof
>>> their code but there current code would now work without having to
>>> rewrite any method bodies (just signatures).
>>>
>>> In light of this I kindly request that RFCs that add nullable types
>>> for only return values be withdrawn. So that [Union Types][2] and
>>> [Nullable Types][3] can go forward unhindered.
>>>
>>>
>>> [1]: https://bugs.php.net/bug.php?id=72119
>>> [2]: https://wiki.php.net/rfc/union_types
>>> [2]: https://wiki.php.net/rfc/nullable_types
>>
>> Hey Dmitry,
>>
>> thanks for reverting… but
>>
>> I've seen you had merged just straight up?
>> I assume this was unintentional (as it should definitely remain fixed in
>> 7.1).
>> Thus I've reverted your changes in master (only) and added an appropriate
>> NEWS entry there.
>>
>> Thanks,
>> Bob
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
