8 years ago by Bob Weinand — view source

unread

Hey,

It has been long enough under discussion...
I've put union types into vote.

Please find the RFC located at:
https://wiki.php.net/rfc/union_types https://wiki.php.net/rfc/union_types

The vote is open until the 23th.

Thanks for voting,
Bob

8 years ago by Derick Rethans — view source

unread

It has been long enough under discussion... I've put union types into
vote.

Please find the RFC located at:
https://wiki.php.net/rfc/union_types https://wiki.php.net/rfc/union_types

Not clear on some of the wording. When you say:

"This RFC proposes a vote on whether ?Foo shall be replaced by Foo |
null in general."

Do you mean that ?Foo will no longer be allowed at all if this RFCs
passes?

cheers,
Derick

8 years ago by Fleshgrinder — view source

unread

Not clear on some of the wording. When you say:

"This RFC proposes a vote on whether ?Foo shall be replaced by Foo |
null in general."

Do you mean that ?Foo will no longer be allowed at all if this RFCs
passes?

cheers,
Derick

Same question here, since https://wiki.php.net/rfc/nullable_types
already passed and directly voiding it makes no sense.

I mentioned this before but maybe it is better to change the RFC to
disallow the question mark if an union type is in use:

OK

?string
null|string
string|null

?SomeClass

BAD

?SomeClass|SomeOtherClass
?SomeOtherClass|SomeClass

?string|int
?int|string

This would be a perfectly valid and reasonable restriction that makes
sense in every way because it helps to avoid ambiguity. However,
disallowing ?T is not.

--
Richard "Fleshgrinder" Fussenegger

8 years ago by Bob Weinand — view source

unread

Am 14.06.2016 um 18:09 schrieb Fleshgrinder php@fleshgrinder.com:

Not clear on some of the wording. When you say:

"This RFC proposes a vote on whether ?Foo shall be replaced by Foo |
null in general."

Do you mean that ?Foo will no longer be allowed at all if this RFCs
passes?

cheers,
Derick

Same question here, since https://wiki.php.net/rfc/nullable_types
already passed and directly voiding it makes no sense.

I mentioned this before but maybe it is better to change the RFC to
disallow the question mark if an union type is in use:

OK

?string
null|string
string|null

?SomeClass

SomeClass|SomeOtherClass|null
null|SomeClass|SomeOtherClass
SomeClass|null|SomeOtherClass

BAD

?SomeClass|SomeOtherClass
?SomeOtherClass|SomeClass

?string|int
?int|string

This would be a perfectly valid and reasonable restriction that makes
sense in every way because it helps to avoid ambiguity. However,
disallowing ?T is not.

--
Richard "Fleshgrinder" Fussenegger

These last ones (which you describe as "BAD" are anyway disallowed.

The separate vote is to remove ?string by string | null as only option.
(It basically just preserves the concept of nullability, but reverses the decision to use a trailing ?. This vote is in order to give those who prefer only foo | null instead of ?foo a chance to voice their opinion.)

Bob

8 years ago by Stanislav Malyshev — view source

unread

Hi!

The separate vote is to remove ?string by string | null as only option.

So we just held a vote on introducing ?type a month ago, to now vote on
removing it. Am I the only one to whom it doesn't make a lot of sense?

--
Stas Malyshev
smalyshev@gmail.com

8 years ago by Fleshgrinder — view source

unread

So we just held a vote on introducing ?type a month ago, to now vote on
removing it. Am I the only one to whom it doesn't make a lot of sense?

Exactly what I question too especially because the other vote was so
overwhelmingly positive.

--
Richard "Fleshgrinder" Fussenegger

8 years ago by Bob Weinand — view source

unread

Am 14.06.2016 um 20:35 schrieb Fleshgrinder php@fleshgrinder.com:

So we just held a vote on introducing ?type a month ago, to now vote on
removing it. Am I the only one to whom it doesn't make a lot of sense?

Exactly what I question too especially because the other vote was so
overwhelmingly positive.

If we'd voted first on unions (and had a separate vote whether to allow null as type), I'm sure the vote would have been just as positive and the nullables RFC not appeared at all.

I'm personally guessing that people mainly wanted to see nullability at all rather than the specific "?" syntax.

Thus there's a separate vote...

Bob

8 years ago by Bob Weinand — view source

unread

Am 14.06.2016 um 17:22 schrieb Derick Rethans derick@php.net:

It has been long enough under discussion... I've put union types into
vote.

Please find the RFC located at:
https://wiki.php.net/rfc/union_types https://wiki.php.net/rfc/union_types

Not clear on some of the wording. When you say:

"This RFC proposes a vote on whether ?Foo shall be replaced by Foo |
null in general."

Do you mean that ?Foo will no longer be allowed at all if this RFCs
passes?

cheers,
Derick

Correct. I think there should be only one way to do that; others may disagree, hence it is a separate vote.

Bob

8 years ago by Zeev Suraski — view source

unread

Hi!

The separate vote is to remove ?string by string | null as only option.

So we just held a vote on introducing ?type a month ago, to now vote on
removing it. Am I the only one to whom it doesn't make a lot of sense?

I actually think this was discussed ahead of time. The thinking was that we'll approve (or reject) nullable types independently without having to wait for union types. If Union types passed - we'd reconsider the syntax for it.

I think we need to clarify the vote here. I'm personally against Union types because it makes no sense for classes, and for scalars we're better off with dedicated solution a (e.g. "numeric"); but if it does pass, I'd rather have just one way of doing nullable types and not two.

Zeev

8 years ago by Levi Morrison — view source

unread

I'm personally against Union types because it makes no sense for classes

I've been over this before but I'll repeat it here for completeness:
this is not true. Unions provide a way to discriminate between
potential sets of types. Even among classes there is power in unions.
Consider the idea of encoding a Something or Nothing with methods such
as map, flatmap, filter, etc.

A Something will return a Something for map, and a Nothing will return
a Nothing. By using inheritance there are two problems:

We can create additional subclasses that do not obey the
semantics of the type. Imagine how frustrating a stack that does not
behave like a stack would be; same principle here.
We don't have covariant return types so we cannot express that
Nothing::map will return Nothing and Something::map will return
Something.

Using two final classes for Something and Nothing and then doing a
union on them has neither of these downsides. Even if we add return
type covariance we cannot solve problem 1.

Given that there are numerous other uses with built-in types such as
Array | Traversable (iterable), int | string (array key), int | float
(numeric) and so forth it does not make sense to me to special case
these things. Generality is better for language features than special
casing.

8 years ago by Bob Weinand — view source

unread

Am 14.6.2016 um 21:53 schrieb Levi Morrison levim@php.net:

I'm personally against Union types because it makes no sense for classes

I've been over this before but I'll repeat it here for completeness:
this is not true. Unions provide a way to discriminate between
potential sets of types. Even among classes there is power in unions.
Consider the idea of encoding a Something or Nothing with methods such
as map, flatmap, filter, etc.

A Something will return a Something for map, and a Nothing will return
a Nothing. By using inheritance there are two problems:

We can create additional subclasses that do not obey the
semantics of the type. Imagine how frustrating a stack that does not
behave like a stack would be; same principle here.

We don't have covariant return types so we cannot express that
Nothing::map will return Nothing and Something::map will return
Something.

Using two final classes for Something and Nothing and then doing a
union on them has neither of these downsides. Even if we add return
type covariance we cannot solve problem 1.

Given that there are numerous other uses with built-in types such as
Array | Traversable (iterable), int | string (array key), int | float
(numeric) and so forth it does not make sense to me to special case
these things. Generality is better for language features than special
casing.

What Levi tries to explain: unions are like a temporary virtual super-interface to any accepted class without actually being implemented by them.

Typically you are writing adapters for these things, but an adapter is not always the solution (i.e. in cases where a part of the handling is identical, but depending on the actual class (instanceof) they ultimately get dispatched to somewhere else).
For exactly these cases (which, I admit, aren’t numerous [The cases where it’s legitimate and there is no other superior solution]) union classes are helpful.

Bob

8 years ago by Zeev Suraski — view source

unread

I'm personally against Union types because it makes no sense for classes

I've been over this before but I'll repeat it here for completeness:
this is not true.

There are more than enough constructs in PHP to handle all these use cases, and handle them nicely. We don't need specialized constructs for every use case.
Either way, no point at redoing the discussion. Apologies if I triggered it, context was only the vote.

Zeev

8 years ago by Levi Morrison — view source

unread

I'm personally against Union types because it makes no sense for classes

I've been over this before but I'll repeat it here for completeness:
this is not true.

There are more than enough constructs in PHP to handle all these use cases,
and handle them nicely. We don't need specialized constructs for every use
case.

To clarify here, you are saying we don't need unions because they are
a special case, yes? But you previously stated you are in favor of
special casing the language types such as numeric?

These are at odds.

8 years ago by Christoph Becker — view source

unread

I'm personally against Union types because it makes no sense for classes

I've been over this before but I'll repeat it here for completeness:
this is not true.

There are more than enough constructs in PHP to handle all these use cases,
and handle them nicely. We don't need specialized constructs for every use
case.

To clarify here, you are saying we don't need unions because they are
a special case, yes? But you previously stated you are in favor of
special casing the language types such as numeric?

These are at odds.

In my opinion, there have to be always compromises when designing a
language for practical purposes. Theoretically, it would not even be
necessary for PHP to have scalar types; everything could be done with
(immutable) objects as well. However, we do have scalar types, and
these are likely to stay, so it seems reasonable to me to add a few
special cases to our type system covering this issue (say, Stringable,
Iterable, numeric, Invokable).

Adding union types as a general mechanism, on the other hand, adds a new
level of complexity for the user which is orthogonal to the classical OO
type system, at least when type definitions will be added, what I
estimate will not take long, due to the verbose inline union typing.
And that is easily going to get out of hand, because independent
libraries might introduce their own LIB\numeric, for instance,
potentially with slightly different definitions (e.g. with or without GMP).

Finally, I don't consider |false a very reasonable thing, because the
respective functions could return a nullable type as well, what would in
my opinion be better anyway for the famous strpos(), which requests the
position of $needle in $haystack, what should be either a numeric index
or NULL (== not present). And at least built-in functions may also
return NULL for wrong argument types, which would require to type their
return values as X|false|null to be exact.

--
Christoph M. Becker

8 years ago by Zeev Suraski — view source

unread

-----Original Message-----
From: morrison.levi@gmail.com [mailto:morrison.levi@gmail.com] On Behalf
Of Levi Morrison
Sent: Wednesday, June 15, 2016 1:51 AM
To: Zeev Suraski zeev@zend.com
Cc: PHP internals internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] [VOTE] Union types

There are more than enough constructs in PHP to handle all these use
cases, and handle them nicely. We don't need specialized constructs
for every use case.

To clarify here, you are saying we don't need unions because they are a
special case, yes? But you previously stated you are in favor of special casing
the language types such as numeric?

These are at odds.

They're not. Let me supplement what I said:

We don't need specialized constructs for every use case; They make sense for ultra-common ones only, and only if the added benefit (compared to doing it using the methods currently available) outweighs the increased cognitive burden.

Hence, 'numeric' makes perfect sense, while a generic Union Types feature does not.

Zeev

8 years ago by Sebastian Bergmann — view source

unread

I'm personally against Union types because it makes no sense for classes, and for scalars we're better off with dedicated solution a (e.g. "numeric");

Same reason I voted no.