Request to withdraw RFC's for nullable types for only return values

10 years ago by Levi Morrison — view source — reply

unread

I have discovered through a bug report 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 and
[Nullable Types][3] can go forward unhindered.

10 years ago by Dmitry Stogov — view source — reply

unread

Hi,

The BC break in PHP-7.0 was introduced by commit ee9a78a033696ff9546fb1dbfecd28f20477b511

Author: Joe Watkins krakjoe@php.net
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.

10 years ago by Bob Weinand — view source — reply

unread

Am 28.04.2016 um 18:28 schrieb Dmitry Stogov dmitry@zend.com:

Hi,

The BC break in PHP-7.0 was introduced by commit ee9a78a033696ff9546fb1dbfecd28f20477b511

Author: Joe Watkins krakjoe@php.net
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: morrison.levi@gmail.com morrison.levi@gmail.com on behalf of Levi Morrison levim@php.net
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 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 and
[Nullable Types][3] can go forward unhindered.

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

10 years ago by Joe Watkins — view source — reply

unread

The problem is as Levi explained though Bob, don't we actually require
nullables/unions for that case ?

Maybe we can move forward now, confident that by the time 7.1 is released
we will have one of those things ?

The problems with that are, the RFC's for unions/intersections don't match
the implementation, and none of us have a good idea how to implement the
RFCs.

In addition, nobody can agree which nullable types RFC should go to vote,
or how the whole nullable type question should be resolved.

Cheers
Joe

Am 28.04.2016 um 18:28 schrieb Dmitry Stogov dmitry@zend.com:

Hi,

The BC break in PHP-7.0 was introduced by commit
ee9a78a033696ff9546fb1dbfecd28f20477b511

Author: Joe Watkins krakjoe@php.net
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: morrison.levi@gmail.com morrison.levi@gmail.com on behalf of
Levi Morrison levim@php.net
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 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 and
[Nullable Types][3] can go forward unhindered.

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

10 years ago by Dmitry Stogov — view source — reply

unread

Thanks for catching the BC break.
Fortunately, we didn't release 7.0.6 with this problem.

I see some sense in introducing that check, but changing behaviour requires RFC and definitely not allowed in minor versions.

I'm not going to withdraw https://wiki.php.net/rfc/nullable_return_types
It doesn't prohibit usage of nullable for arguments, and even sets additional question.

Thanks. Dmitry.

10 years ago by Joe Watkins — view source — reply

unread

Evening Dmitry,

This was discussed at length with bob, and I think nikita also, it seemed
like a bug fix rather than a feature.

Happy for it to be moved into 7.1 ... sorry for dropping the ball there ...

Cheers
Joe

Thanks for catching the BC break.
Fortunately, we didn't release 7.0.6 with this problem.

I see some sense in introducing that check, but changing behaviour
requires RFC and definitely not allowed in minor versions.

I'm not going to withdraw https://wiki.php.net/rfc/nullable_return_types
It doesn't prohibit usage of nullable for arguments, and even sets
additional question.

Thanks. Dmitry.

From: morrison.levi@gmail.com morrison.levi@gmail.com on behalf of Levi
Morrison levim@php.net
Sent: Thursday, April 28, 2016 6:40:59 PM
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 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 and
[Nullable Types][3] can go forward unhindered.

10 years ago by Levi Morrison — view source — reply

unread

Thanks for catching the BC break.
Fortunately, we didn't release 7.0.6 with this problem.

I see some sense in introducing that check, but changing behaviour requires RFC and definitely not allowed in minor versions.

I'm not going to withdraw https://wiki.php.net/rfc/nullable_return_types
It doesn't prohibit usage of nullable for arguments, and even sets additional question.

In that case: are you fine with my RFCs going to vote first (and
soon)? We presently have four somewhat competing RFCs and need to work
out voting order.

Tom: are you willing to withdraw or wait for my RFCs to vote first?

10 years ago by Dmitry Stogov — view source — reply

unread

hi Joe,

No problem, great it's fixed before 7.0.6 release.

I think this change might be introduced only together with nullable or union types.

Otherwise it makes a problem, described by Levi, that doesn't allow running the same code in PHP-7.0 and 7.1, and even doesn't allow an ease fix.

Thanks. Dmitry.

10 years ago by Bob Weinand — view source — reply

unread

Am 28.04.2016 um 19:28 schrieb Dmitry Stogov dmitry@zend.com:

hi Joe,

No problem, great it's fixed before 7.0.6 release.

I think this change might be introduced only together with nullable or union types.

Otherwise it makes a problem, described by Levi, that doesn't allow running the same code in PHP-7.0 and 7.1, and even doesn't allow an ease fix.

Thanks. Dmitry.

From: Joe Watkins pthreads@pthreads.org
Sent: Thursday, April 28, 2016 8:20:12 PM
To: Dmitry Stogov
Cc: Levi Morrison; internals; Tom Worster
Subject: Re: Request to withdraw RFC's for nullable types for only return values

Evening Dmitry,

This was discussed at length with bob, and I think nikita also, it seemed like a bug fix rather than a feature.

Happy for it to be moved into 7.1 ... sorry for dropping the ball there ...

Cheers
Joe

Thanks for catching the BC break.
Fortunately, we didn't release 7.0.6 with this problem.

I see some sense in introducing that check, but changing behaviour requires RFC and definitely not allowed in minor versions.

I'm not going to withdraw https://wiki.php.net/rfc/nullable_return_types
It doesn't prohibit usage of nullable for arguments, and even sets additional question.

Thanks. Dmitry.

From: morrison.levi@gmail.com mailto:morrison.levi@gmail.com <morrison.levi@gmail.com mailto:morrison.levi@gmail.com> on behalf of Levi Morrison <levim@php.net mailto:levim@php.net>
Sent: Thursday, April 28, 2016 6:40:59 PM
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 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 and
[Nullable Types][3] can go forward unhindered.

Uhm … reading this, it sounds like it was intentional … if yes, then sorry.

But it still allows an easy fix, just pass the value explicitly.
I think we should leave the fix in 7.1 thus.

The bug itself - violating LSP - must be fixed. The only reason why it's fine in 7.0 is BC. But it definitely MUST be fixed in 7.1.

Bob

10 years ago by Dmitry Stogov — view source — reply

unread

your Nullable RFC doesn't propose working implementation.

10 years ago by Levi Morrison — view source — reply

unread

your Nullable RFC doesn't propose working implementation.

From: morrison.levi@gmail.com morrison.levi@gmail.com on behalf of Levi Morrison levim@php.net
Sent: Thursday, April 28, 2016 8:39:03 PM
To: Dmitry Stogov
Cc: internals; Tom Worster
Subject: Re: Request to withdraw RFC's for nullable types for only return values

Thanks for catching the BC break.
Fortunately, we didn't release 7.0.6 with this problem.

I see some sense in introducing that check, but changing behaviour requires RFC and definitely not allowed in minor versions.

I'm not going to withdraw https://wiki.php.net/rfc/nullable_return_types
It doesn't prohibit usage of nullable for arguments, and even sets additional question.

In that case: are you fine with my RFCs going to vote first (and
soon)? We presently have four somewhat competing RFCs and need to work
out voting order.

Tom: are you willing to withdraw or wait for my RFCs to vote first?

It doesn't have an implementation, sure. But you already worked out
return types, the basics are already there in parameter types and
there's an implementation in HHVM. Do you really think this would be a
blocker? There is no reason to believe that a short-hand nullable
types implementation cannot be reasonably done.

10 years ago by Joe Watkins — view source — reply

unread

Levi,

Why do you need to block Dmitry's return type nullable RFC ?

We need to move forward, that has an implementation, ready for a long

time, doesn't seem to block nullable parameter types rfc, either separately
or as part of unions.

So, I'm not understanding why you need to hold up Dmitry any more.

Please, explain.

Cheers
Joe

your Nullable RFC doesn't propose working implementation.

From: morrison.levi@gmail.com morrison.levi@gmail.com on behalf of
Levi Morrison levim@php.net
Sent: Thursday, April 28, 2016 8:39:03 PM
To: Dmitry Stogov
Cc: internals; Tom Worster
Subject: Re: Request to withdraw RFC's for nullable types for only
return values

Thanks for catching the BC break.
Fortunately, we didn't release 7.0.6 with this problem.

I see some sense in introducing that check, but changing behaviour
requires RFC and definitely not allowed in minor versions.

I'm not going to withdraw
https://wiki.php.net/rfc/nullable_return_types
It doesn't prohibit usage of nullable for arguments, and even sets
additional question.

In that case: are you fine with my RFCs going to vote first (and
soon)? We presently have four somewhat competing RFCs and need to work
out voting order.

Tom: are you willing to withdraw or wait for my RFCs to vote first?

It doesn't have an implementation, sure. But you already worked out
return types, the basics are already there in parameter types and
there's an implementation in HHVM. Do you really think this would be a
blocker? There is no reason to believe that a short-hand nullable
types implementation cannot be reasonably done.

10 years ago by Levi Morrison — view source — reply

unread

Levi,
Why do you need to block Dmitry's return type nullable RFC ?

We need to move forward, that has an implementation, ready for a long
time, doesn't seem to block nullable parameter types rfc, either separately
or as part of unions.
So, I'm not understanding why you need to hold up Dmitry any more.

Please, explain.
Cheers
Joe

your Nullable RFC doesn't propose working implementation.

From: morrison.levi@gmail.com morrison.levi@gmail.com on behalf of
Levi Morrison levim@php.net
Sent: Thursday, April 28, 2016 8:39:03 PM
To: Dmitry Stogov
Cc: internals; Tom Worster
Subject: Re: Request to withdraw RFC's for nullable types for only
return values

Thanks for catching the BC break.
Fortunately, we didn't release 7.0.6 with this problem.

I see some sense in introducing that check, but changing behaviour
requires RFC and definitely not allowed in minor versions.

I'm not going to withdraw
https://wiki.php.net/rfc/nullable_return_types
It doesn't prohibit usage of nullable for arguments, and even sets
additional question.

In that case: are you fine with my RFCs going to vote first (and
soon)? We presently have four somewhat competing RFCs and need to work
out voting order.

Tom: are you willing to withdraw or wait for my RFCs to vote first?

It doesn't have an implementation, sure. But you already worked out
return types, the basics are already there in parameter types and
there's an implementation in HHVM. Do you really think this would be a
blocker? There is no reason to believe that a short-hand nullable
types implementation cannot be reasonably done.

--

Let me firstly say I'm not trying to "block" Dmitry's RFC as some sort
of political campaign. Let me try to straighten this:

As evidenced by this bug report that needs a fix there is a need for
nullable parameter types that is not tied to a default of null.
Dmitry's RFC does not handle this. Nor does Tom's.

There is an RFC that can solve both return types and parameter types.
I'm asking them to withdraw because they don't meet those needs and
there is an RFC that does. It just so happens to be mine. It also
happens to be the first drafted RFC.

This is not an unreasonable request. In fact, it's the much nicer
option that just opening vote on mine first without talking about it
on list at all. And lastly, it's just a request. They don't have to
withdraw.

10 years ago by Dmitry Stogov — view source — reply

unread

all these are good points not to commit BC breaks in hurry.

10 years ago by Dmitry Stogov — view source — reply

unread

I'm not happy with the fact, that you propose two competing RFCs, support only one and trying to withdraw other competitors.

10 years ago by Dmitry Stogov — view source — reply

unread

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.

10 years ago by Bob Weinand — view source — reply

unread

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 dmitry@zend.com:

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 bobwei9@hotmail.com
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 dmitry@zend.com:

Hi,

The BC break in PHP-7.0 was introduced by commit ee9a78a033696ff9546fb1dbfecd28f20477b511

Author: Joe Watkins krakjoe@php.net
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: morrison.levi@gmail.com morrison.levi@gmail.com on behalf of Levi Morrison levim@php.net
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 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 and
[Nullable Types][3] can go forward unhindered.

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

10 years ago by Dmitry Stogov — view source — reply

unread

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.

10 years ago by Bob Weinand — view source — reply

unread

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 dmitry@zend.com:

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 bobwei9@hotmail.com
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 dmitry@zend.com:

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 bobwei9@hotmail.com
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 dmitry@zend.com:

Hi,

The BC break in PHP-7.0 was introduced by commit ee9a78a033696ff9546fb1dbfecd28f20477b511

Author: Joe Watkins krakjoe@php.net
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: morrison.levi@gmail.com morrison.levi@gmail.com on behalf of Levi Morrison levim@php.net
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 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 and
[Nullable Types][3] can go forward unhindered.

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

10 years ago by Dmitry Stogov — view source — reply

unread

Levi, I don't understand, why do you keep trying to own "Nullable Types" RFC, if you like completely different "Union Types".

10 years ago by Levi Morrison — view source — reply

unread

Levi, I don't understand, why do you keep trying to own "Nullable Types" RFC, if you like completely different "Union Types".

I don't understand; I wrote the RFC. What do you mean, "keep trying to
own" it? I wrote both Nullable Types and Union Types. Some view those
RFC's as competing, but they can also be orthogonal. I see the value
in having both.

10 years ago by Dmitry Stogov — view source — reply

unread

Levi, I provided an implementation for your RFC on February 2015, and I would be glad if your RFC was accepted that time.
Bit since that time you block it in respect to "Union Types"

See conversation at PR https://github.com/php/php-src/pull/1045

I would be also glad if your "Nullable Types" RFC was accepted now, but I don't trust in your intention to support it.

10 years ago by Tom Worster — view source — reply

unread

Levi,

From one reasonable point of view, Union and Nullable are in conflict with
each other. If one prefers Union then one might argue in favor of Union
over related but different proposals. When it comes to the vote, it's
difficult to support both except with the argument that "I can settle for
Nullable if Union doesn't pass vote", which, when you think about it, is
not really supporting both.

If Union goes to vote before anything else, voters will to take into
account what they expect to subsequently go to vote. So your stance
relative to that matters. Hence it's not really clear what you want while
you continue to own both.

This is how I understand Dmitry's concerns (correct me if I'm wrong,
Dmitry).

It would be easier to understand if you would either abandon Union (for
7.1) and throw your support behind Nullable or disown Nullable, let
Dmitry champion it, and the two RFCs to vote as alternatives.

I understand that you see Union as a kind of superset of Nullable (correct
me if I'm wrong) but when it comes to the voting, there's no fair way to
organize that. Someone's going to be unhappy.

Tom

Levi, I provided an implementation for your RFC on February 2015, and I
would be glad if your RFC was accepted that time.
Bit since that time you block it in respect to "Union Types"

See conversation at PR https://github.com/php/php-src/pull/1045

I would be also glad if your "Nullable Types" RFC was accepted now, but I
don't trust in your intention to support it.

From: morrison.levi@gmail.com morrison.levi@gmail.com on behalf of Levi
Morrison levim@php.net
Sent: Thursday, April 28, 2016 10:02:20 PM
To: Dmitry Stogov
Cc: Joe Watkins; internals; Tom Worster
Subject: Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types
for only return values

Levi, I don't understand, why do you keep trying to own "Nullable
Types" RFC, if you like completely different "Union Types".

I don't understand; I wrote the RFC. What do you mean, "keep trying to
own" it? I wrote both Nullable Types and Union Types. Some view those
RFC's as competing, but they can also be orthogonal. I see the value
in having both.

10 years ago by Dmitry Stogov — view source — reply

unread

More or less right. It's easy to archive the "right" goal, if you own the both football teams.

Request to withdraw RFC's for nullable types for only return values View as Markdown