Re: [PHP-DEV] [RFC] Union Types v2

[Björn Larsson]

Den 2019-09-26 kl. 10:06, skrev Nikita Popov:


On Tue, Sep 24, 2019 at 10:06 PM Sara Golemon  wrote:


On Tue, Sep 24, 2019 at 12:24 PM Claude Pache 
wrote:

The choice of supporting precisely the two literal values `null` and

`false`

is not arbitrary: They are the two values that are the most often used as
sentinel values (for indicating failure or absence). It is true that

`true` is

also sometimes used as sentinel value (more rarely and not among the
internal functions), but the same can be said of other literal values
(one of your examples includes `0`).


While I personally think `false` makes sense as an allowed "type", I also
don't want to see the union types RFC get held up on such a tiny detail.

I would propose either of the following alternatives:
1/ Remove `false` from the proposal. It can always be added at a later
time, but not taken away.
2/ Make this detail a sub-vote.  I would suggest that this sub-vote should
also be subject to a 2/3 majority in order to pass.

-Sara


This RFC is currently held up by a lack of implementation. Once that is
done, the RFC will go forward as-is (barring any novel concerns). Because I
consider it an important part of the overall proposal (*), I will neither
remove the false type, nor split it into a separate vote. People may vote
against the whole RFC if they disagree with this aspect, or any other
aspect of the proposal.

Regards,
Nikita

(*) While certainly not the primary reason for why we should support union
types, the reason why I brought this proposal forward at this time
specifically, is that the lack of union types is a blocker for my pet
project of providing comprehensive type annotations for internal functions.
Supporting "false" is strictly necessary for this purpose, because it is
part of nearly all unions as far as internal functions are concerned.


Hi Nikita,

Given the feedback on 23/9 from B Morel regarding
occurrence of true as a return value, would you then
consider adding true as a valid return type in unions?

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Union Types v2

[Benjamin Morel]

> While certainly not the primary reason for why we should support union
types, the reason why I brought this proposal forward at this time
specifically, is that the lack of union types is a blocker for my pet
project of providing comprehensive type annotations for internal functions.
Supporting "false" is strictly necessary for this purpose, because it is
part of nearly all unions as far as internal functions are concerned.
How is that blocked by adding only "bool"?

— Benjamin

Re: [PHP-DEV] [RFC] Union Types v2

[Christoph M. Becker]

On 26.09.2019 at 10:06, Nikita Popov wrote:

> This RFC is currently held up by a lack of implementation. Once that is
> done, the RFC will go forward as-is (barring any novel concerns). Because I
> consider it an important part of the overall proposal (*), I will neither
> remove the false type, nor split it into a separate vote. People may vote
> against the whole RFC if they disagree with this aspect, or any other
> aspect of the proposal.
>
> (*) While certainly not the primary reason for why we should support union
> types, the reason why I brought this proposal forward at this time
> specifically, is that the lack of union types is a blocker for my pet
> project of providing comprehensive type annotations for internal functions.
> Supporting "false" is strictly necessary for this purpose, because it is
> part of nearly all unions as far as internal functions are concerned.

Maybe an option would be to introduce "falsable" types by marking them
with an exclamation mark in front?  While I'm generally not in favor of
having failure signalled by returning false (except for bool functions),
and it wouldn't solve the issue generally (some functions can return
multiple types in addition to false), it appears to fit to be able to
mark nullable types with a question mark.

By the way, I wouldn't call that a "pet project".  In my opinion, that
is a really big improvement, and I hope that these stub files can become
the single source of truth in the not too distant future.

Regards,
Christoph

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Union Types v2

[Claude Pache]

> Le 26 sept. 2019 à 11:21, Lynn  a écrit :
> 
> 
> I'm not sure this type should be declarable in user-land, meaning it's 
> limited to the core and a marker for legacy.

In general, we should avoid to give builtin code functionality that can’t be 
reproduced in userland, unless there is a good reason for it. For the 
particular case, people may want to reproduce in userland an improved or 
corrected version of a given internal function, and they need be able to give 
their function the same return type information than the original.

—Claude

Re: [PHP-DEV] [RFC] Union Types v2

[Lynn]

On Thu, Sep 26, 2019 at 10:06 AM Nikita Popov  wrote:

>
> This RFC is currently held up by a lack of implementation. Once that is
> done, the RFC will go forward as-is (barring any novel concerns). Because I
> consider it an important part of the overall proposal (*), I will neither
> remove the false type, nor split it into a separate vote. People may vote
> against the whole RFC if they disagree with this aspect, or any other
> aspect of the proposal.
>
> Regards,
> Nikita
>
> (*) While certainly not the primary reason for why we should support union
> types, the reason why I brought this proposal forward at this time
> specifically, is that the lack of union types is a blocker for my pet
> project of providing comprehensive type annotations for internal functions.
> Supporting "false" is strictly necessary for this purpose, because it is
> part of nearly all unions as far as internal functions are concerned.
>

Hi,

What if a 'new' type is added specifically to identify this case? Instead
of giving it `int|false`, it could be `int|failed`, where `failed` would
allow a single value only: false. I like it more than naming the return
type `false`. I'm not sure this type should be declarable in user-land,
meaning it's limited to the core and a marker for legacy. `failed` (or name
it whatever) and `false` would still be identical, yet has a more distinct
identification and does not imply there could also a type called `true`.

Figured I'd toss in here as an out-of-the-box idea.

Regards,
Lynn van der Berg

Re: [PHP-DEV] [RFC] Union Types v2

[Nikita Popov]

On Tue, Sep 24, 2019 at 10:06 PM Sara Golemon  wrote:

> On Tue, Sep 24, 2019 at 12:24 PM Claude Pache 
> wrote:
> > The choice of supporting precisely the two literal values `null` and
> `false`
> > is not arbitrary: They are the two values that are the most often used as
> > sentinel values (for indicating failure or absence). It is true that
> `true` is
> > also sometimes used as sentinel value (more rarely and not among the
> > internal functions), but the same can be said of other literal values
> > (one of your examples includes `0`).
> >
> While I personally think `false` makes sense as an allowed "type", I also
> don't want to see the union types RFC get held up on such a tiny detail.
>
> I would propose either of the following alternatives:
> 1/ Remove `false` from the proposal. It can always be added at a later
> time, but not taken away.
> 2/ Make this detail a sub-vote.  I would suggest that this sub-vote should
> also be subject to a 2/3 majority in order to pass.
>
> -Sara
>

This RFC is currently held up by a lack of implementation. Once that is
done, the RFC will go forward as-is (barring any novel concerns). Because I
consider it an important part of the overall proposal (*), I will neither
remove the false type, nor split it into a separate vote. People may vote
against the whole RFC if they disagree with this aspect, or any other
aspect of the proposal.

Regards,
Nikita

(*) While certainly not the primary reason for why we should support union
types, the reason why I brought this proposal forward at this time
specifically, is that the lack of union types is a blocker for my pet
project of providing comprehensive type annotations for internal functions.
Supporting "false" is strictly necessary for this purpose, because it is
part of nearly all unions as far as internal functions are concerned.

Re: [PHP-DEV] [RFC] Union Types v2

[Benjamin Morel]

>  I would tend to agree with Sara.  That seems to be the only issue of
contention and it is (AFAIK) reasonably straightforward to add "later"
without blocking the rest of Union types.  It would mean some functions
wouldn't be able to get a fully accurate return type yet but... they've
survived this long without them, they can wait a bit longer while this gets
settled and/or some even more robust alternative is found.

Note that I'm personally alright with only bool as a type (i.e. strpos() :
int|bool). I was just pointing out that introducing false alone is adding
yet another inconsistency to the language, and it may not need this right
now.

If everything is to be voted at once, I'd suggest a split vote as follows:

- vote 1: introduce union types (base proposal with bool only) : yes / no
- vote 2: add false/true types: false only / false and true / no

— Benjamin

Re: [PHP-DEV] [RFC] Union Types v2

[Larry Garfield]

On Tue, Sep 24, 2019, at 3:05 PM, Sara Golemon wrote:
> On Tue, Sep 24, 2019 at 12:24 PM Claude Pache 
> wrote:
> > The choice of supporting precisely the two literal values `null` and
> `false`
> > is not arbitrary: They are the two values that are the most often used as
> > sentinel values (for indicating failure or absence). It is true that
> `true` is
> > also sometimes used as sentinel value (more rarely and not among the
> > internal functions), but the same can be said of other literal values
> > (one of your examples includes `0`).
> >
> While I personally think `false` makes sense as an allowed "type", I also
> don't want to see the union types RFC get held up on such a tiny detail.
> 
> I would propose either of the following alternatives:
> 1/ Remove `false` from the proposal. It can always be added at a later
> time, but not taken away.
> 2/ Make this detail a sub-vote.  I would suggest that this sub-vote should
> also be subject to a 2/3 majority in order to pass.
> 
> -Sara

I would tend to agree with Sara.  That seems to be the only issue of contention 
and it is (AFAIK) reasonably straightforward to add "later" without blocking 
the rest of Union types.  It would mean some functions wouldn't be able to get 
a fully accurate return type yet but... they've survived this long without 
them, they can wait a bit longer while this gets settled and/or some even more 
robust alternative is found.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Union Types v2

[Sara Golemon]

On Tue, Sep 24, 2019 at 12:24 PM Claude Pache 
wrote:
> The choice of supporting precisely the two literal values `null` and
`false`
> is not arbitrary: They are the two values that are the most often used as
> sentinel values (for indicating failure or absence). It is true that
`true` is
> also sometimes used as sentinel value (more rarely and not among the
> internal functions), but the same can be said of other literal values
> (one of your examples includes `0`).
>
While I personally think `false` makes sense as an allowed "type", I also
don't want to see the union types RFC get held up on such a tiny detail.

I would propose either of the following alternatives:
1/ Remove `false` from the proposal. It can always be added at a later
time, but not taken away.
2/ Make this detail a sub-vote.  I would suggest that this sub-vote should
also be subject to a 2/3 majority in order to pass.

-Sara

Re: [PHP-DEV] [RFC] Union Types v2

[Claude Pache]

> Le 23 sept. 2019 à 22:14, Benjamin Morel  a écrit :
> 
> 
> So although true as a type does not have the same historical background as
> false, it does seem that it's being used by enough packages to be worth
> considering; what do you think?
> 

Considering to support `true` will raise several questions. They can be 
resolved, of course, but that will put more design decisions over the shoulders 
of the Union Types RFC:

* The first one, of course, is why the list of possible literal values is 
*still* restricted. Because now you’ll want to use other literal values, e.g., 
`0` or `"some-string"`.

* Another issue is the relation between `Foo | false | true` and `Foo | bool`: 
whether the first form is allowed; whether they are equivalent w.r.t. variance 
rules; how casting to `true | false` works (or doesn’t work) under 
`declare(strict_types=0)`.

* Also, if we support more than two literal values as types (and especially 
when not all of them indicate failure), we’ll want more strongly to have them 
to appear as standalone types, e.g.,  `true | null`; and then, naturally, just 
`true` and just `null`. At this point, the question will be raised whether it 
is desirable to have both `null` and `void` as return types.

-

The choice of supporting precisely the two literal values `null` and `false` is 
not arbitrary: They are the two values that are the most often used as sentinel 
values (for indicating failure or absence). It is true that `true` is also 
sometimes used as sentinel value (more rarely and not among the internal 
functions), but the same can be said of other literal values (one of your 
examples includes `0`).

—Claude

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Kalle Sommer Nielsen]

Den tir. 10. sep. 2019 kl. 13.14 skrev Rowan Tommins :
> That's a reasonable point; that (and the inverse: governments blocking
> access to github in response to some perceived offence) would be a
> potential issue to weigh up against the risks of running our own
> infrastructure.

We are already under the US law when it comes to distribution of
software as our binaries (like Windows) which contains encryption
software for export since we potentially allow countries which the US
have an embargo with, such as Iran (or more recently Venezuela). If I
remember correctly its partly the reason why PHP is registered as an
entity in the US to comply with EAR. How this is dealt with under the
hood of the project and all of  that I have no idea, but even as it
is, we are not currently operating in a noman's land and already live
with restrictions imposed by the governments of the world.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Rowan Tommins]

On Tue, 10 Sep 2019 at 10:39, Lynn  wrote:

>
> Are you aware of any heavy-handed moderation on github, or is this, again,
>> a hypothetical problem?
>>
>
> As much as I like Github for these kind of things, we're forgetting about
> a critical part here; The US trade restrictions. Github being a company in
> the US, is required to block certain access to users from certain countries.
>


That's a reasonable point; that (and the inverse: governments blocking
access to github in response to some perceived offence) would be a
potential issue to weigh up against the risks of running our own
infrastructure.

Regards,
-- 
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Lynn]

On Tue, Sep 10, 2019 at 11:02 AM Rowan Tommins 
wrote:

> On Tue, 10 Sep 2019 at 08:37, Côme Chilliet  wrote:
>
> > It’s not the same when the project can act to fix it and when the project
> > is powerless.
> > If github blocks someone from commenting we cannot do anything about it.
>
>
> Are you aware of any heavy-handed moderation on github, or is this, again,
> a hypothetical problem?
>

As much as I like Github for these kind of things, we're forgetting about a
critical part here; The US trade restrictions. Github being a company in
the US, is required to block certain access to users from certain countries.

Regards,
Lynn van der Berg

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Rowan Tommins]

On Tue, 10 Sep 2019 at 08:37, Côme Chilliet  wrote:

> > >  PHP have no control over github, and cannot know how it will evolve.
> > >
> > >  (they can change the platform tomorrow and internal won’t be able to
> do anything about it).
> >
> > Those are hypothetically problems. But they do not appear to be
> > currently problems.
>
> The fact that PHP has no control over github is current, this is not
> hypothetical.
>


The idea that the platform will change overnight in a way that makes it
unusable by the project is hypothetical.




> It’s not the same when the project can act to fix it and when the project
> is powerless.
> If github blocks someone from commenting we cannot do anything about it.
>


Are you aware of any heavy-handed moderation on github, or is this, again,
a hypothetical problem?

As you will see from my other responses on this thread, I'm not totally
sold on github in particular, but I can see pros and cons more generally:

- our own systems, fully in our control, but used by nobody else, and
managed by a handful of volunteers
- or: a well-established third-party system, which could change in
unpredictable ways, but is widely used, and supported by hundreds of paid
staff

Even the mailing list relies on third-party software; I presume it gets
updated regularly, and those updates could include changes in functionality
we disagree with. There is a pragmatic decision to be made between building
absolutely everything from scratch, and trusting some third parties, with
contingency plans if that trust proves ill-founded.

Regards,
-- 
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Côme Chilliet]

Le vendredi 6 septembre 2019, 16:47:52 CEST Nikita Popov a écrit :
>  * GitHub would not be the exclusive venue for RFC discussion. All RFCs are
> still announced on internals and the top-level discussion can and should
> still happen here.

My remark on the mailing list regarding string|true was unanswered and I had to 
go over to github to see that the concern was discussed there.
This is the kind of problems splitting the discussion will cause, people will 
have to check both places or miss things.

Regarding the github PR as a practical point of view, I find it hard to check 
if there are new messages since last time I visited the page. Is there any way 
to browse messages by time? (backwards ideally).

Côme

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Côme Chilliet]

Le jeudi 5 septembre 2019, 13:07:28 CEST Dan Ackroyd a écrit :
> On Thu, 5 Sep 2019 at 12:27, Côme Chilliet  wrote:
> >
> >  PHP have no control over github, and cannot know how it will evolve.
> >
> >  (they can change the platform tomorrow and internal won’t be able to do 
> > anything about it).
> 
> Those are hypothetically problems. But they do not appear to be
> currently problems.

The fact that PHP has no control over github is current, this is not 
hypothetical.

> And in case anyone says "some people might not be able to comment on
> Github" the same is true for our email lists. The signup process was
> apparently broken for ages, and I've seen multiple people ask for how
> to persuade the system to accept their messages. Which probably means
> there are more people who never contributed because they couldn't get
> past that first barrier.

It’s not the same when the project can act to fix it and when the project is 
powerless.
If github blocks someone from commenting we cannot do anything about it.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Rowan Tommins]

On 8 September 2019 11:42:07 BST, Brent  wrote:
> - We could add community guidelines, clearly stating that RFC comments
>should stay on topic
> - People could be appointed to moderate the comments, allowing
>contributors to focus on the code instead of community management
> - Conversations on GitHub can be locked as a last measurement.
>Repository members can still comment.
>
>I fear that separating the main discussion from the PR will cause
>unnecessary confusion: important, generals remarks could be made on the
>"main thread", and I think there's value in keeping these remarks
>together with everything else.


I'm sceptical of that as a solution for two reasons:

Firstly, the conversations weren't necessarily wrong, they were just a slight 
drift of topic. The problem is not removing them from the PR, it's encouraging 
them to move somewhere else. I fear that saying "sign up to the mailing list 
and repeat that point in a completely different format" will be taken up less 
than "make a new thread on this same list/forum".  

Secondly, the problem is partly a technical one: GitHub PRs have very poor 
support for replies and sub-threads, so even on-topic discussions that don't 
relate to a specific part of the text are hard to follow.

I think Nikita's suggestion is a good one: use a PR for making targeted 
suggestions to the RFC text itself, but raise the general points on the main 
list. That might even include saying "I've added a handful of suggestions 
relating to X" and discussing the wider issue that links them.

I agree it would be interesting to experiment further, and I think this hybrid 
approach would be a good one to try next.

Regards,

-- 
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Brent]

Happy to read your thoughts on this Nikita, I think you've drawn some good 
conclusions.

If I may add a thought or two:

I wouldn't make any final decisions based on one experiment, especially a big 
RFC as this one. I think the GitHub discussion got extra attention because it 
was the first one, and because of the scope of the RFC. I would try to have two 
or three more RFCs discussed on GitHub, maybe smaller ones?

Second, there are more things we can do in order to keep the main thread on 
topic. Three things come to mind:

 - We could add community guidelines, clearly stating that RFC comments should 
stay on topic
 - People could be appointed to moderate the comments, allowing contributors to 
focus on the code instead of community management
 - Conversations on GitHub can be locked as a last measurement. Repository 
members can still comment.

I fear that separating the main discussion from the PR will cause unnecessary 
confusion: important, generals remarks could be made on the "main thread", and 
I think there's value in keeping these remarks together with everything else.

Kind regards
Brent
On 6 Sep 2019, 16:48 +0200, Nikita Popov , wrote:
> Here are my own thoughts on how the pull request discussion for union types
> went...
>
> I think the main takeaway for me is that inline comments (on specific lines
> in the RFC) were really invaluable. Each comment thread discussed a
> specific issue and most of them have resulted in a direct improvement to
> the RFC.
>
> Generally there was a lot of discussion of specific technical details that
> we very rarely see in RFC discussions. Current RFC discussions on the
> mailing list tend to be rather high level (which is fine in itself), with
> nobody ever discussing the details (which is very bad).
>
> Thinking back to https://wiki.php.net/rfc/engine_warnings, I think that RFC
> could have really benefited from this discussion medium. While the mailing
> list discussion ended up talking circles around more or less one single
> question (undefined variables), pretty much none of the other parts of the
> RFC have seen so much as a comment. I'm sure that there would be a lot more
> discussion regarding specific classifications if this went up as a pull
> request.
>
> Another nice thing is that it's possible to mark a comment thread as
> resolved, once the RFC has been adjusted to address the comments. That way
> you don't have to see issues that were already addressed (though you can if
> you like).
>
> Having thumbs-up and thumbs-down reactions to comments was also helpful to
> judge whether some comment represents a minority opinion or not, something
> that is notoriously hard with current mailing list discussions (which are
> almost dominated by "negative" opinions which mysteriously don't show up in
> voting results).
>
> However, while the inline comments were pleasantly insightful, the same
> cannot be said for the top-level comments on the pull request. The majority
> of them was borderline off-topic. While some in principle interesting
> discussion happened there, it simply didn't belong in the RFC thread for
> union types. The top-level comments also suffered from a lack of threading
> -- I would have been less bothered about tangential discussions if they
> were threaded. (To be fair: I use gmail, so I don't get threading on the
> mailing list either.)
>
> If this kind of discussion behavior is representative, then I would suggest
> a workflow alone the following lines...
>
> * RFCs are submitted as PRs on GitHub, but must be announced on the mailing
> list.
> * The PR description should have a fat warning that top-level comments
> belong on the mailing list. We can mark all top-level comments on PRs as
> "off-topic" as a matter of general policy.
> * Top-level commentary stays on the mailing list.
>
> This is a shift from what I originally had in mind (completely moving the
> RFC process to GitHub), towards providing a way for more detailed and
> specific feedback on the RFC text.
>
> Regarding GitHub as a 3rd party. I think there are a few things to
> considered:
> * We're already very heavily reliant on GitHub. Most of my day-to-day
> interaction with PHP core development is via GitHub and most of the
> day-to-day decisions also happen there. Only the major stuff everhits this
> mailing list.
> * The RFC repo would of course be hosted on git.php.net as usual and only
> be mirrored to GitHub.
> * GitHub would not be the exclusive venue for RFC discussion. All RFCs are
> still announced on internals and the top-level discussion can and should
> still happen here.
>
> Disclaimer: I'm trying to draw conclusions here from an experiment with a
> sample size of 1, which may not be representative. Union types are a pretty
> significant proposal (and also the first one to be on GH), and other,
> smaller proposals might well have different discussion dynamics.
>
> Regards,
> Nikita
>
> On Thu, Sep 5, 2019 at 12:22 PM Côme Chilliet  wrote:
>
> > Le jeudi 5 

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Nikita Popov]

Here are my own thoughts on how the pull request discussion for union types
went...

I think the main takeaway for me is that inline comments (on specific lines
in the RFC) were really invaluable. Each comment thread discussed a
specific issue and most of them have resulted in a direct improvement to
the RFC.

Generally there was a lot of discussion of specific technical details that
we very rarely see in RFC discussions. Current RFC discussions on the
mailing list tend to be rather high level (which is fine in itself), with
nobody ever discussing the details (which is very bad).

Thinking back to https://wiki.php.net/rfc/engine_warnings, I think that RFC
could have really benefited from this discussion medium. While the mailing
list discussion ended up talking circles around more or less one single
question (undefined variables), pretty much none of the other parts of the
RFC have seen so much as a comment. I'm sure that there would be a lot more
discussion regarding specific classifications if this went up as a pull
request.

Another nice thing is that it's possible to mark a comment thread as
resolved, once the RFC has been adjusted to address the comments. That way
you don't have to see issues that were already addressed (though you can if
you like).

Having thumbs-up and thumbs-down reactions to comments was also helpful to
judge whether some comment represents a minority opinion or not, something
that is notoriously hard with current mailing list discussions (which are
almost dominated by "negative" opinions which mysteriously don't show up in
voting results).

However, while the inline comments were pleasantly insightful, the same
cannot be said for the top-level comments on the pull request. The majority
of them was borderline off-topic. While some in principle interesting
discussion happened there, it simply didn't belong in the RFC thread for
union types. The top-level comments also suffered from a lack of threading
-- I would have been less bothered about tangential discussions if they
were threaded. (To be fair: I use gmail, so I don't get threading on the
mailing list either.)

If this kind of discussion behavior is representative, then I would suggest
a workflow alone the following lines...

* RFCs are submitted as PRs on GitHub, but must be announced on the mailing
list.
* The PR description should have a fat warning that top-level comments
belong on the mailing list. We can mark all top-level comments on PRs as
"off-topic" as a matter of general policy.
* Top-level commentary stays on the mailing list.

This is a shift from what I originally had in mind (completely moving the
RFC process to GitHub), towards providing a way for more detailed and
specific feedback on the RFC text.

Regarding GitHub as a 3rd party. I think there are a few things to
considered:
 * We're already very heavily reliant on GitHub. Most of my day-to-day
interaction with PHP core development is via GitHub and most of the
day-to-day decisions also happen there. Only the major stuff everhits this
mailing list.
 * The RFC repo would of course be hosted on git.php.net as usual and only
be mirrored to GitHub.
 * GitHub would not be the exclusive venue for RFC discussion. All RFCs are
still announced on internals and the top-level discussion can and should
still happen here.

Disclaimer: I'm trying to draw conclusions here from an experiment with a
sample size of 1, which may not be representative. Union types are a pretty
significant proposal (and also the first one to be on GH), and other,
smaller proposals might well have different discussion dynamics.

Regards,
Nikita

On Thu, Sep 5, 2019 at 12:22 PM Côme Chilliet  wrote:

> Le jeudi 5 septembre 2019, 12:04:55 CEST Brent a écrit :
> > > Huge "no" from me on using github for discussing RFCs.
> >
> > Care to elaborate why? The majority seems to like it. Though I am also
> curious about Nikita's experience with it, as he is the one having to
> process the feedback.
>
> Because the PHP project should avoid depending on a privately owned
> centralized service for its technical discussions, and should not encourage
> (some would say force) people to use such platforms.
>
> PHP is already on github but it’s only a mirror, the main git repository
> is at git.php.net .
>
> Côme
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Benjamin Morel]

>
> That's pretty much the opposite of your previous question. For one thing,
> it's unanswerable without knowing the scope - e.g. would it just be for
> RFCs, or all discussions?


I'm thinking about a generic "forum" for all discussions that happen on the
mailing lists right now, something that could be used for internals but
also for other PHP mailing lists.

Then, its scope can be expanded specifically for internals, to better
discuss RFCs, etc., but that's not what I had in mind right now.

Until we know what we're looking for, I'm really not clear why GitHub
> issues should have any starting advantage over Discourse, or PHPBB, or
> Trac, or Phabricator, or Bugzilla, or probably hundreds of suggestions we
> could evaluate.


I chose GitHub because it was mentioned several times in this thread,
because it's already used to discuss PRs, and because I suspect pretty much
everyone on this list either uses GitHub on a daily basis, or has at
least *some
*experience with GitHub issues (let's face it, I google stuff every day for
many open-source projects, and most of the discussions I stumble upon are
on GitHub issues/pulls), so at least we have a* starting point* that
everyone knows and has learned to love or hate. Now the whole point is, if
you think another software does things better, please share!

Now obviously, should you hate GitHub issues from start to finish, then
indeed I can understand you consider this starting point a poor choice, in
this case I'd be interested to know what you dislike so much!

— Benjamin

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Rowan Tommins]

On Fri, 6 Sep 2019 at 14:14, Benjamin Morel 
wrote:

> As a code collaboration platform, GitHub is pretty good, but it's not built
>> as a discussion forum, and there are plenty of limitations to using it as
>> one.
>
>
> Could we work on agreeing on a set of requirements for such a discussion
> "forum" to replace mailing lists?
>


That could be an interesting exercise, yes. Ideally, we should consider RFC
drafting, voting, and bug tracking as well - not because we have to replace
all of them with one platform, but because we might want to divide things
up differently from how we do at the moment.




> Using GitHub Issues as a starting point, what would you change?
>


That's pretty much the opposite of your previous question. For one thing,
it's unanswerable without knowing the scope - e.g. would it just be for
RFCs, or all discussions?

Besides that, if we're going to introduce an anchor that we compare
everything to, surely we should say "using the setup we have as a starting
point, what would you change?"

Until we know what we're looking for, I'm really not clear why GitHub
issues should have any starting advantage over Discourse, or PHPBB, or
Trac, or Phabricator, or Bugzilla, or probably hundreds of suggestions we
could evaluate.

Regards,
-- 
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Benjamin Morel]

>
> As a code collaboration platform, GitHub is pretty good, but it's not built
> as a discussion forum, and there are plenty of limitations to using it as
> one.


Could we work on agreeing on a set of requirements for such a discussion
"forum" to replace mailing lists? That would make it easier for anyone
wanting to give it a shot, to come up with a first version that has a
chance to convince everyone that this is the direction we want to follow.

Using GitHub Issues as a starting point, what would you change?

— Benjamin

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Rowan Tommins]

On Fri, 6 Sep 2019 at 12:31, Peter Kokot  wrote:

>
> Plastic analogy - adding "127.0.0.1 github.com" to your /etc/hosts
> file shows that developer cannot bring most of the today's (PHP)
> projects to any working state without using it. That's what is meant
> by inevitable because everything open source today is either on GitHub
> and some minor ones scattered around custom Git repos and other Git
> hosting providers.
>


Ah, I see. Yes, having some usage of GitHub is currently pretty much
inevitable in that sense. Of course, that may change eventually, just as
SourceForge fell out of favour, but that's not something we need to worry
about.

However, projects over a certain size generally *don't* use it as their
main or only discussion platform, which is what we're talking about here.



> PHP is already using GitHub. Is it moving to
> something else? No, so let's not complicate things more with other
> hosting providers now.
>


The question is not "should PHP ban the use of GitHub for any kind of
activity?" it's "should PHP abandon the discussion processes it's been
using for most of its history and use GitHub as a discussion forum?".

As a code collaboration platform, GitHub is pretty good, but it's not built
as a discussion forum, and there are plenty of limitations to using it as
one.

Regards,
-- 
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Peter Kokot]

On Fri, 6 Sep 2019 at 11:11, Rowan Tommins  wrote:
>
> On Thu, 5 Sep 2019 at 22:45, Peter Kokot  wrote:
>
> > GitHub usage is inevitable.
>
>
>
> Did you use the wrong word here, or are you saying that, of all the
> hundreds of different platforms we could investigate, there is no chance
> that we would end up using something other than github?

Plastic analogy - adding "127.0.0.1 github.com" to your /etc/hosts
file shows that developer cannot bring most of the today's (PHP)
projects to any working state without using it. That's what is meant
by inevitable because everything open source today is either on GitHub
and some minor ones scattered around custom Git repos and other Git
hosting providers. PHP is already using GitHub. Is it moving to
something else? No, so let's not complicate things more with other
hosting providers now.

USA political issues and embargo on some countries are indeed a reason
I'm also willing to accept that PHP won't be using GitHub otherwise.
For other reasons presented here, none is  convincing enough to me
honestly.


-- 
Peter Kokot

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Pierre Joye]

On Thu, Sep 5, 2019, 5:51 PM Joe Watkins  wrote:

> > Because the PHP project should avoid depending on a privately owned
> centralized service for its technical discussions
>
> This is obviously your opinion, but you haven't actually told us why this
> is the case, and it's not at all obvious.
>
> > should not encourage (some would say force) people to use such platforms.
>
> In any case it's not a choice for the contributor, internals chooses the
> medium and the contributor has to use it. Whether we force them to use a
> mailing list from last century or something from this century makes no
> difference with regard to choice for the contributor.


I am not worrying when one uses it for draft. However anything after that
should happen in the wiki and on our git as it is the correct process.

I really like github, or gitlab, however int he current context, almost all
contributors may lose access to github (or other US based) companies based
on the US government policies or directives. Without starting a political
discussion whether or not this is valid, it is definitely a big risk. A
risk I am not really willing to take for php itself, if I may say.

best,

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Rowan Tommins]

On Thu, 5 Sep 2019 at 22:45, Peter Kokot  wrote:

> GitHub usage is inevitable.



Did you use the wrong word here, or are you saying that, of all the
hundreds of different platforms we could investigate, there is no chance
that we would end up using something other than github?



> The interface is so good with clear discussion and review options
>


As my previous message, and those of several other people, show, that is
far from an established consensus. The power of an e-mail list is that
different users can use different interfaces - I've yet to see a forum
suggested that I would find easier than Thunderbird's tree view. There are
certainly downsides to e-mail, and upsides to GitHub, but let's stay calm
and evaluate our options rather than jumping at the first thing we see.

Regards,
-- 
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Kalle Sommer Nielsen]

Den tor. 5. sep. 2019 kl. 13.22 skrev Côme Chilliet :
> Because the PHP project should avoid depending on a privately owned 
> centralized service for its technical discussions, and should not encourage 
> (some would say force) people to use such platforms.
>
> PHP is already on github but it’s only a mirror, the main git repository is 
> at git.php.net .

As an old timer around here, I feel very strongly about moving the
medium and I prefer to be on the PHP.net infrastructure. Clearly one
of our biggest issues with that as the PHP organization is that we
poorly maintain it, and I think it could be time to rather invest into
renewing that effort instead. It seems like many have an issue with
subscribing to internals (I know it was broken for the longest time by
using the webform), but that is something we can telegraph better on
the php.net website for one thing and try to put resources into
figuring this problem out to gain momentum for more developers to join
the effort of internals development.

Using Github for PRs and relevant discussions for that is perfectly
fine with me, but switching to Github for RFCs is a big -1 from me, it
is really difficult to read new comments if you are not email
subscribed and even then it still remains hard to follow. The
individual moderation required to also sort out irrelevant comments is
also one thing I personally would not want to deal with either.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Mark Randall]

On 05/09/2019 22:45, Benjamin Morel wrote:

. One
thing that could be checked, is whether their API allows retrieving the
whole discussion history programmatically. If so, one could setup a
database to sync all messages to on a regular basis, so that the PHP
project could move the discussions back to their own system should
something bad happen.


Certainly appears to

https://developer.github.com/v3/pulls/comments/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Benjamin Morel]

I've thought about this many times while reading messages on internals, but
from another perspective: the inability to "+1" a message without having to
reply. I very often find myself agreeing (or disagreeing) with someone, but
refrain myself from posting a one-liner to show my support. Having
something like GitHub reactions to be able to "+1" or "-1" a message could
be invaluable to get the overall sentiment of the participants (even the
silent readers) when browsing through the thread.

When I browse an issue or a PR on GitHub, the reactions help me quickly see
which messages stand out of the crowd, be it positively or negatively, and
usually help me get quickly a good idea of what's going on there, when I
don't have the time to read through every single message.

IMO, replacing the mailing list with a GitHub-like discussion would bring
several advantages:

- no more top-posting, etc.: this would be a web app, not a dumb email
software that (sometimes unreliably) quotes everything by default.
- possibility to use markdown: invaluable to make a message more readable
- possibility to add reactions to messages, even from silent readers
- possibility to react to previous messages, for someone who just joined
the list, without having to invoke ezmlm black magic

Also, I think this would lower the level of entry to internals for a lot of
PHP developers who aren't otherwise interested in participating in
discussions, but could appreciate being able to give their opinion on the
future of PHP. And for maintainers, this would represent invaluable
feedback to see the sentiment from the crowd, not only from the usual
suspects.

Externals.io does a pretty good job, but suffers from many drawbacks that
can hardly be solved:

- it's still reading emails, so while it does a good job at putting
everyting together quite nicely, it's sometimes confused by the syntax,
especially quoting
- you can vote on threads (stackoverflow-style), but not on individual
messages; and because externals.io is not everyone's main way of reading
through internals, this lowers the number of potential reactions
- there is no way to reply to a message, you have to get back to your email
- there is no real support for markdown; a few things are supported, but I
find them quite unreliable and am never really happy with how my
hand-crafted message looks over there

Ideally, we could create a custom web app to move the discussions to. I'd
love to participate in creating it, even initiate the project, if time
permits. This would also allow adding interesting stuff, like user
statistics, user post history, etc.)

Finally, regarding GitHub, I'm personally not against moving the
discussions there; I'm using it every day and find it very convenient to
discuss software; I do understand the concerns expressed above though. One
thing that could be checked, is whether their API allows retrieving the
whole discussion history programmatically. If so, one could setup a
database to sync all messages to on a regular basis, so that the PHP
project could move the discussions back to their own system should
something bad happen.

— Benjamin

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Peter Kokot]

Hello,

On Thu, 5 Sep 2019 at 12:22, Côme Chilliet  wrote:
>
> Le jeudi 5 septembre 2019, 12:04:55 CEST Brent a écrit :
> > > Huge "no" from me on using github for discussing RFCs.
> >
> > Care to elaborate why? The majority seems to like it. Though I am also 
> > curious about Nikita's experience with it, as he is the one having to 
> > process the feedback.
>
> Because the PHP project should avoid depending on a privately owned 
> centralized service for its technical discussions, and should not encourage 
> (some would say force) people to use such platforms.
>
> PHP is already on github but it’s only a mirror, the main git repository is 
> at git.php.net .
>
> Côme

If I may put few random thoughts here. GitHub usage is inevitable. The
interface is so good with clear discussion and review options that it
would be really worthy to check it out for all PHP RFCS in the future.
The main worry here is basically that one day GitHub will go offline
and that discussion will be lost. Repository however will stay in the
Git repo and will be "timeless". Very rarely one will want to look at
the old (several 10 years) discussion comments. This is not a problem
because even with having an email archive online very rarely someone
will return to such discussion. RFC content is there and will be there
for PHP to move "elsewhere" though if such hypothetical case comes.

Tank you.


-- 
Peter Kokot

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Rowan Tommins]

On Thu, 5 Sep 2019 at 13:05, Mark Randall  wrote:

> Something I am finding hard on Github, and maybe it's just because I
> haven't found the option yet, is finding new posts.
>


Yes, so far, I've been forced to choose between two imperfect options:

- follow the discussion using the e-mail notifications only, giving worse
context for the sub-threads than I'd get on a mailing list
- scanning all the sub-threads on the PR to see if there are new replies I
haven't read yet

The ability to attach sub-threads to lines in the PR is certainly useful
for some types of discussion, but a lot of the longer threads would be
better off with just a subject line.

Regards,
-- 
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Dan Ackroyd]

On Thu, 5 Sep 2019 at 14:29, Brent  wrote:
>
> I believe GitHub is the way to go. Several large communities manage their OSS 
> on it and have proven it works, PHP should simply do the same.

At the risk of giving advice, you will find conversations are far more
productive if you ask why something can't be done, rather than just
stating it will be simple.

Not only will that elicit more useful information to you, it avoids
being subtly insulting, as you're implying that something will be easy
and people are being stupid for not doing it*.

In this particular case you could have asked "what would be the
problems with moving the build systems to github?", and the answers
would include:

* PHP has karma (aka permissions) system which github could not
support. I don't know how that could be solved/avoided.

* There is very strong reluctance to be dependent on other people's
infrastructure for things that could take a long time to migrate. e.g.
we can move discussions from one medium to another, by just telling
people to go talk over there. But for actual software CI, it's a big
deal to move from one system to another.

btw it's not obvious that the projects you linked actually have their
build systems integrated with Github. I'm pretty sure you're making
assumptions about how simple their systems are.

cheers
Dan
Ack

* in pithier form: https://signalvnoise.com/posts/439-four-letter-words

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Rowan Tommins]

On Thu, 5 Sep 2019 at 14:29, Brent  wrote:

> I believe GitHub is the way to go. Several large communities manage their
> OSS on it and have proven it works, PHP should simply do the same.
>


I think this is just as simplistic as saying "never". What are these
communities using it for, and what would we want to use it for? Are our
requirements the same as theirs, and is GitHub the best solution for those
requirements?

For instance:

- Rust does not use GitHub as its primary co-ordination mechanism, it has
an online forum at https://internals.rust-lang.org/
- The ECMA TC39 committee has a specific membership structure and holds
regular in-person meetings
- There are undoubtedly more open-source communities _not_ using GitHub
than who _are_ using it

To be clear, I'm not saying these are reasons against GitHub in themselves,
but it's a rather huge leap from "here are four repos I found" to "GitHub
is the way to go"; we should be making specific arguments for why it will
meet our needs, and evaluating it among all the alternatives.

Regards,
-- 
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Brent]

Let's name a few examples of large OSS projects managed on GitHub:

 - ECMA (https://github.com/tc39)
 - Rust (https://github.com/rust-lang/rust)
 - React (https://github.com/facebook/react)
 - Node (https://github.com/nodejs/node)

Also, let's not forget the hunderd of thousands of PHP packages hosted on 
GitHub. While GitHub might _in theory_ one day decide to stop, there is no way 
it will happen in practice, GitHub has proven itself as a reliable platform 
over the past ten years.

On the topic of self hosted GitLab: let's not reinvent the wheel. Managing your 
own platform will take more manpower and resources, which are better invested 
somewhere else — the development of PHP perhaps?

I believe GitHub is the way to go. Several large communities manage their OSS 
on it and have proven it works, PHP should simply do the same.

Kind regards
Brent
On 5 Sep 2019, 15:14 +0200, George Peter Banyard , wrote:
> One idea could be to use a self hosted GitLab instance,
>
> I'm pretty sure there are multiple ways via OAuth to connect to an
> independent GitLab instance.
>
> This would allow to have PR like thread on PHP's own infrastructure (even
> though it seems the project is pretty bad at keeping it's infrastructure up
> to date) while keeping control over it.
>
> Best regards
>
> George Peter Banyard

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[George Peter Banyard]

One idea could be to use a self hosted GitLab instance,

I'm pretty sure there are multiple ways via OAuth to connect to an
independent GitLab instance.

This would allow to have PR like thread on PHP's own infrastructure (even
though it seems the project is pretty bad at keeping it's infrastructure up
to date) while keeping control over it.

Best regards

George Peter Banyard

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Dan Ackroyd]

On Thu, 5 Sep 2019 at 12:27, Côme Chilliet  wrote:
>
>  PHP have no control over github, and cannot know how it will evolve.
>
>  (they can change the platform tomorrow and internal won’t be able to do 
> anything about it).
>

Those are hypothetically problems. But they do not appear to be
currently problems.

I'm pretty sure that if new problems with a medium were encountered,
we could adapt to either work around them or move to a different
system.

And in case anyone says "some people might not be able to comment on
Github" the same is true for our email lists. The signup process was
apparently broken for ages, and I've seen multiple people ask for how
to persuade the system to accept their messages. Which probably means
there are more people who never contributed because they couldn't get
past that first barrier.


Actual problems I can see with having the discussion on github:

i) There is no off-topic space. For example, apparently some people
don't understand the RFC and could do with a brief explainer on type
systems. Doing that inline to the github comments would make the
on-topic discussion harder to read.

ii) It means that the discussion is harder to track. However.that
is already a problem. When I was putting together the info for
https://github.com/danack/RfcCodex which attempts to document why
certain ideas that keep coming up haven't succeeded yet, it was a
massive pain trying to track email threads to the RFC.

Both of those things are not really technical problems. They are
documentation problems. They would be best solved (imo) by having a
paid member of staff on the PHP project writing lots of words.

cheers
Dan
Ack

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Mark Randall]

On 05/09/2019 12:08, Rowan Tommins wrote:

but at least views
like externals.io and news.php.net can let you navigate the tree.


The lack of a full tree-like structure isn't the worst thing in the 
world. If only because it discourages certain types of individual from 
wanting to reply to every single sub-branch individually to get the 
final word.


Something I am finding hard on Github, and maybe it's just because I 
haven't found the option yet, is finding new posts.


Mark Randall

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Côme Chilliet]

Le jeudi 5 septembre 2019, 12:50:48 CEST Joe Watkins a écrit :
> > Because the PHP project should avoid depending on a privately owned 
> > centralized service for its technical discussions
> 
> This is obviously your opinion, but you haven't actually told us why this
> is the case, and it's not at all obvious.

I thought it was obvious, sorry.
So, the problem is PHP have no control over github, and cannot know how it will 
evolve.

GAFAM organizations have closed people accounts before, sometimes without 
giving reasons.
I think PHP project should not let other organisations choose who can or cannot 
participate in PHP development.

> > should not encourage (some would say force) people to use such platforms.
> 
> In any case it's not a choice for the contributor, internals chooses the
> medium and the contributor has to use it. Whether we force them to use a
> mailing list from last century or something from this century makes no
> difference with regard to choice for the contributor.

With a mailing list the contributor can choose its email server and email 
client. He does not have to agree to term of service of a third party.
https://tosdr.org/#github
With github, internal chooses to delegate to github, and github (currently 
microsoft) chooses who can take part in the discussion and how the discussion 
works. (they can change the platform tomorrow and internal won’t be able to do 
anything about it).

Côme

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Rowan Tommins]

On Thu, 5 Sep 2019 at 11:22, Côme Chilliet  wrote:

> Le jeudi 5 septembre 2019, 12:04:55 CEST Brent a écrit :
> > > Huge "no" from me on using github for discussing RFCs.
> >
> > Care to elaborate why? The majority seems to like it. Though I am also
> curious about Nikita's experience with it, as he is the one having to
> process the feedback.
>
> Because the PHP project should avoid depending on a privately owned
> centralized service for its technical discussions, and should not encourage
> (some would say force) people to use such platforms.
>
> PHP is already on github but it’s only a mirror, the main git repository
> is at git.php.net .
>


The "privately owned" and "centralized" parts don't bother me particularly,
but there's potentially an issue in splitting the discussion between
multiple platforms, with different logins required. An example of this is
the discussion on this RFC about type aliases - Nikita requested it to be
split into a separate discussion, but the people involved may not be
subscribed to this list, and if they are, it's hard to maintain context
when jumping between different forums.

That conversation also highlighted a limitation of the particular platform:
inline comments on GitHub PRs show as threads, but comments on the whole PR
don't, so that interleaved discussions are hard to follow. Admittedly,
that's true on a lot of e-mail clients as well (thanks to GMail
popularising "conversations" rather than "threads"), but at least views
like externals.io and news.php.net can let you navigate the tree.

I wonder if a hybrid approach would work better - the RFC is a PR (perhaps
against the language spec repo, as Andrea suggested) but the main
discussion stays on the list. Suggestions to improve the RFC itself could
be made inline on the PR by anyone who wanted to, but non-inline PR
comments would be heavily discouraged so that wider comments on the
proposal would stay here.

Either way, I think it's interesting to experiment with different ways of
working, and maybe there are other platforms we should trial as well.

Regards,
-- 
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Joe Watkins]

> Because the PHP project should avoid depending on a privately owned
centralized service for its technical discussions

This is obviously your opinion, but you haven't actually told us why this
is the case, and it's not at all obvious.

> should not encourage (some would say force) people to use such platforms.

In any case it's not a choice for the contributor, internals chooses the
medium and the contributor has to use it. Whether we force them to use a
mailing list from last century or something from this century makes no
difference with regard to choice for the contributor.

Cheers
Joe

On Thu, 5 Sep 2019 at 12:22, Côme Chilliet  wrote:

> Le jeudi 5 septembre 2019, 12:04:55 CEST Brent a écrit :
> > > Huge "no" from me on using github for discussing RFCs.
> >
> > Care to elaborate why? The majority seems to like it. Though I am also
> curious about Nikita's experience with it, as he is the one having to
> process the feedback.
>
> Because the PHP project should avoid depending on a privately owned
> centralized service for its technical discussions, and should not encourage
> (some would say force) people to use such platforms.
>
> PHP is already on github but it’s only a mirror, the main git repository
> is at git.php.net .
>
> Côme
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Côme Chilliet]

Le jeudi 5 septembre 2019, 12:04:55 CEST Brent a écrit :
> > Huge "no" from me on using github for discussing RFCs.
> 
> Care to elaborate why? The majority seems to like it. Though I am also 
> curious about Nikita's experience with it, as he is the one having to process 
> the feedback.

Because the PHP project should avoid depending on a privately owned centralized 
service for its technical discussions, and should not encourage (some would say 
force) people to use such platforms.

PHP is already on github but it’s only a mirror, the main git repository is at 
git.php.net .

Côme

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Union Types v2

[Brent]

Hi Côme

> Huge "no" from me on using github for discussing RFCs.

Care to elaborate why? The majority seems to like it. Though I am also curious 
about Nikita's experience with it, as he is the one having to process the 
feedback.

Kind regards
Brent
On 5 Sep 2019, 11:40 +0200, Côme Chilliet , wrote:
> Le mercredi 4 septembre 2019, 10:26:09 CEST Nikita Popov a écrit :
> > As an experiment, I'm submitting this RFC as a GitHub pull request, to
> > evaluate whether this might be a better medium for RFC proposals in the
> > future. It would be great if we could keep the discussion to the GitHub
> > pull request for the purpose of this experiment (keep in mind that you can
> > also create comments on specific lines in the proposal, not just the
> > overall discussion thread!) Of course, you can also reply to this mail
> > instead. The final vote will be held in the wiki as usual.
>
> Huge "no" from me on using github for discussing RFCs.
>
> Huge "yes" on the RFC content.
>
> > * Only supports "false" as a pseudo-type, not "true".
>
> I think it would make sense to support true as well as I’ve seen a lot of 
> cases of functions returning either an error string or TRUE on success.
> So that would be string|true.
>
> Côme
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] [RFC] Union Types v2

[Côme Chilliet]

Le mercredi 4 septembre 2019, 10:26:09 CEST Nikita Popov a écrit :
> As an experiment, I'm submitting this RFC as a GitHub pull request, to
> evaluate whether this might be a better medium for RFC proposals in the
> future. It would be great if we could keep the discussion to the GitHub
> pull request for the purpose of this experiment (keep in mind that you can
> also create comments on specific lines in the proposal, not just the
> overall discussion thread!) Of course, you can also reply to this mail
> instead. The final vote will be held in the wiki as usual.

Huge "no" from me on using github for discussing RFCs.

Huge "yes" on the RFC content.

>  * Only supports "false" as a pseudo-type, not "true".

I think it would make sense to support true as well as I’ve seen a lot of cases 
of functions returning either an error string or TRUE on success.
So that would be string|true.

Côme

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Union Types v2

[Claude Pache]

> Le 4 sept. 2019 à 13:54, Dan Ackroyd  a écrit :
> 
>> 
>> if we were to use "?int" instead, the engine would force the
>> community to add "return null;"
> 
> That sounds like a bug to me. The fact that null is returned by any
> function that lacks an explicit return value, is well-defined, and one
> of the most underrated aspects of PHP imo.
> 

This is an aspect of the eternal debate between explicit vs. implicit. In 
another recent thread, another aspect, namely variable initialisation, was 
debated. There is no “correct” solution, as it pertains much to coding style.

—Claude

Re: [PHP-DEV] [RFC] Union Types v2

[Dan Ackroyd]

On Wed, 4 Sep 2019 at 10:59, Nicolas Grekas
 wrote:

> we use "@return $this" quite often. On the implementation side, I'd
> suggest enforcing this at compile time only (enforce all return points are
> explicit, and written as "return $this"

That's doing a deeper level of thing than a type system normal does.

It's enforcing the internal behaviour of a function, rather than just
defining the type of the parameter that is returned.


> if we were to use "?int" instead, the engine would force the
> community to add "return null;"

That sounds like a bug to me. The fact that null is returned by any
function that lacks an explicit return value, is well-defined, and one
of the most underrated aspects of PHP imo.


Arnold Daniels wrote:
> Instead of using `__toString` as type maybe it's better to introduce
> a `Stringable` interface,

Although casting things to string is probably the most common use
case, if you're going to think about an RFC along those lines,
covering all of the scalars would probably be a good idea, as that
would allow people to use specific types for values, that can then be
passed easily to functions that expect a scalar.

function setRetryLimit(int $maxRetries) {...}

class ImageUploadRetryLimit extends int {...}

function processImage(ImageUploadRetryLimit $iurl, ) {
...
setRetryLimit($iurl);
...
}

That type* of stuff is completely possible currently in PHP, it's just
that it's a bit painful to both write and read.

cheers
Dan
Ack


*intended

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Union Types v2

[Peter Bowyer]

On Wed, 4 Sep 2019 at 12:30, Arnold Daniels 
wrote:

> Instead of using `__toString` as type maybe it's better to introduce a
> `Stringable` interface, similar to how `__wakeup` and `__sleep` are already
> superseded by `Serializable`.


I support that.  I don't like the naming in `string|__toString`.
`string|Stringable` is more readable IMO.

Peter

Re: [PHP-DEV] [RFC] Union Types v2

[Arnold Daniels]

Instead of using `__toString` as type maybe it's better to introduce a 
`Stringable` interface, similar to how `__wakeup` and `__sleep` are already 
superseded by `Serializable`. Of course `__toString` would still continue to 
work (for bc), but isn't usable for type hinting.

[Arnold Daniels - Chat @ 
Spike](https://www.spikenow.com/?ref=spike-organic-signature&_ts=5acb3)
[5acb3]

On September 4, 2019 at 9:59 GMT, Nicolas Grekas  
wrote:

Re: [PHP-DEV] [RFC] Union Types v2

[Matthew Brown]

- Agree on the usefulness of a stringable meta-type.

- Hack supports an explicit “: this” return type (without dollar) when 
returning “new static(...)”. I think I might prefer that to “: static”.

- From a type perspective, I don’t understand the “int|void” idea - it might 
make your users’ life easier, but doesn’t accord with how PHP works (which 
treats void as null to consumers).

- if we’re adding to some future wish list, would love to have support for “: 
noreturn” when a function always throws or exits

On Sep 4, 2019, at 5:58 AM, Nicolas Grekas  wrote:

>> 
>> https://github.com/nikic/php-rfcs/blob/union-types/rfcs/-union-types-v2.md
> 
> 
> Thank you Nikita, this would be a hugely welcomed step forward! Can't wait
> to get rid of all those docblock annotations!
> 
> I've some additional suggestions that would greatly help remove more
> docblocks and provide engine-enforced type-safety, maybe for the "future
> scope" section. We use the all in Symfony:
> 
>   - we miss a stringable union type, for `string|__toString`. This is
>   required when an API need lazyness regarding the generation of some
>   strings. Right now, we have no other option but using string|object.
>   - we use "@return $this" quite often. On the implementation side, I'd
>   suggest enforcing this at compile time only (enforce all return points are
>   explicit, and written as "return $this", similarly to what is done for
>   nullable/void return types.) This makes sense only for return types.
>   - we use "@return static" quite often too, typically when a method
>   returns a clone of the current instance. If anyone wonders, this is not the
>   same as "@return self" of methods overridden in child classes. This makes
>   sense only for return types.
> 
> About union types with void in them, we do use one in Symfony:
> Command::execute() has "@return int|void". The reason is that if we were to
> use "?int" instead, the engine would force the community to add "return
> null;" where no return statement is needed at all most of the time. Right
> now, we consider that the transition cost for the community is not worth
> the extra boilerplate this requires. Note that there would be only one
> friendly path forward: trigger a deprecation when null is returned, asking
> ppl to add  "return 0;". Not sure how this should impact the proposal, but
> I thought it could be worth sharing.
> 
> Thanks again,
> Nicolas

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Union Types v2

[Nicolas Grekas]

>
> https://github.com/nikic/php-rfcs/blob/union-types/rfcs/-union-types-v2.md


Thank you Nikita, this would be a hugely welcomed step forward! Can't wait
to get rid of all those docblock annotations!

I've some additional suggestions that would greatly help remove more
docblocks and provide engine-enforced type-safety, maybe for the "future
scope" section. We use the all in Symfony:

   - we miss a stringable union type, for `string|__toString`. This is
   required when an API need lazyness regarding the generation of some
   strings. Right now, we have no other option but using string|object.
   - we use "@return $this" quite often. On the implementation side, I'd
   suggest enforcing this at compile time only (enforce all return points are
   explicit, and written as "return $this", similarly to what is done for
   nullable/void return types.) This makes sense only for return types.
   - we use "@return static" quite often too, typically when a method
   returns a clone of the current instance. If anyone wonders, this is not the
   same as "@return self" of methods overridden in child classes. This makes
   sense only for return types.

About union types with void in them, we do use one in Symfony:
Command::execute() has "@return int|void". The reason is that if we were to
use "?int" instead, the engine would force the community to add "return
null;" where no return statement is needed at all most of the time. Right
now, we consider that the transition cost for the community is not worth
the extra boilerplate this requires. Note that there would be only one
friendly path forward: trigger a deprecation when null is returned, asking
ppl to add  "return 0;". Not sure how this should impact the proposal, but
I thought it could be worth sharing.

Thanks again,
Nicolas

Re: [PHP-DEV] [RFC] Union Types v2

[Aegir Leet]

On the subject of using GitHub for this RFC:

Personally, I think GitHub is a much better platform than the mailing 
list for this kind of discussion. Mailing list threads are just not very 
accessible to the average PHP user. Reading them through externals.io is 
an OK experience, but actually contributing is unnecessarily complicated.

I'd imagine most people aren't really interested in something like the 
recent "Annotating internal function argument and return types​" thread, 
but would very much like to participate in a discussion (even if it's 
just leaving a "+1") about something that affects their day-to-day work, 
like union types.

Generally, I'd split things up like this:
Truly internal work on PHP itself, things only people working *on* PHP 
(as opposed to *with* PHP) really care about -> internals.
Changes affecting regular PHP users, RFCs for adding or removing 
features and things like that -> GitHub or some other platform where 
everyone can easily contribute.


On 04.09.19 10:26, Nikita Popov wrote:
> Hi internals,
>
> I'd like to start the discussion on union types again, with a new proposal:
>
> Pull Request: https://github.com/php/php-rfcs/pull/1
> Rendered Proposal:
> https://github.com/nikic/php-rfcs/blob/union-types/rfcs/-union-types-v2.md
>
> As an experiment, I'm submitting this RFC as a GitHub pull request, to
> evaluate whether this might be a better medium for RFC proposals in the
> future. It would be great if we could keep the discussion to the GitHub
> pull request for the purpose of this experiment (keep in mind that you can
> also create comments on specific lines in the proposal, not just the
> overall discussion thread!) Of course, you can also reply to this mail
> instead. The final vote will be held in the wiki as usual.
>
> Relatively to the previous proposal by Bob (
> https://wiki.php.net/rfc/union_types), I think the main differences in this
> proposal are:
>   * Updated to specify interaction with new language features, like full
> variance and property types.
>   * Updated for the use of the ?Type syntax rather than the Type|null syntax.
>   * Only supports "false" as a pseudo-type, not "true".
>   * Slightly simplified semantics for the coercive typing mode.
>
> Regards,
> Nikita
>

Re: [PHP-DEV] [RFC] Union Types v2

[Marco Pivetta]

Hey Nikita,

On Wed, Sep 4, 2019 at 10:26 AM Nikita Popov  wrote:

> Hi internals,
>
> I'd like to start the discussion on union types again, with a new proposal:
>
> Pull Request: https://github.com/php/php-rfcs/pull/1
> Rendered Proposal:
>
> https://github.com/nikic/php-rfcs/blob/union-types/rfcs/-union-types-v2.md
>
> As an experiment, I'm submitting this RFC as a GitHub pull request, to
> evaluate whether this might be a better medium for RFC proposals in the
> future. It would be great if we could keep the discussion to the GitHub
> pull request for the purpose of this experiment (keep in mind that you can
> also create comments on specific lines in the proposal, not just the
> overall discussion thread!) Of course, you can also reply to this mail
> instead. The final vote will be held in the wiki as usual.
>

Huge huge huge +1! Reviewing line-by-line allowed me to go much more in
detail with the feedback :-)

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

[PHP-DEV] [RFC] Union Types v2

[Nikita Popov]

Hi internals,

I'd like to start the discussion on union types again, with a new proposal:

Pull Request: https://github.com/php/php-rfcs/pull/1
Rendered Proposal:
https://github.com/nikic/php-rfcs/blob/union-types/rfcs/-union-types-v2.md

As an experiment, I'm submitting this RFC as a GitHub pull request, to
evaluate whether this might be a better medium for RFC proposals in the
future. It would be great if we could keep the discussion to the GitHub
pull request for the purpose of this experiment (keep in mind that you can
also create comments on specific lines in the proposal, not just the
overall discussion thread!) Of course, you can also reply to this mail
instead. The final vote will be held in the wiki as usual.

Relatively to the previous proposal by Bob (
https://wiki.php.net/rfc/union_types), I think the main differences in this
proposal are:
 * Updated to specify interaction with new language features, like full
variance and property types.
 * Updated for the use of the ?Type syntax rather than the Type|null syntax.
 * Only supports "false" as a pseudo-type, not "true".
 * Slightly simplified semantics for the coercive typing mode.

Regards,
Nikita

Re: [PHP-DEV] [RFC] Union Types

[Marcio Almada]

Hi! You are everywhere :P

2016-04-17 6:28 GMT-04:00 Lin Yo-An :
> I think it will be better if union type is only allowed in the "type"
> statement, like what you described in your RFC.
>
> type Iterable = Array  | Traversable;
>
> If we can always pre-define the types.
>
> And only allow just one type for each function parameter in the function
> prototype, then, I think the performance impact of type checking in the
> runtime might be able to be reduced.
>
> In other words, you predefine the union type before you used them, and the
> union types can be reused in different functions, you don't write a lot
> union type in function prototype.

Performance issues aside, the ability to inline type expressions on
function signatures --- function myMethod(A|B $arg){...} --- can be "nice"
because it allows us to keep type definitions *private*. Assuming that a
named type could be reused by third party code (as public API) and that may
not always be the intended.

Of course this would be much better addressed with first class packages
where interfaces, classes, types etc can have their visibility defined. But
until we get there, having the type expressions on argument lists may be
useful.

Cheers,
Márcio

Re: [PHP-DEV] [RFC] Union Types

[Lin Yo-An]

I think it will be better if union type is only allowed in the "type"
statement, like what you described in your RFC.

type Iterable = Array  | Traversable;

If we can always pre-define the types.

And only allow just one type for each function parameter in the function
prototype, then, I think the performance impact of type checking in the
runtime might be able to be reduced.

In other words, you predefine the union type before you used them, and the
union types can be reused in different functions, you don't write a lot
union type in function prototype.

Re: [PHP-DEV] [RFC] Union Types

[Björn Larsson]

Den 2016-04-14 kl. 16:25, skrev Levi Morrison:

On Thu, Apr 14, 2016 at 3:12 AM, Derick Rethans  wrote:

On Wed, 13 Apr 2016, Levi Morrison wrote:


As alluded to in an earlier email today[1] I am now moving the Union
Types RFC[2] to the discussion phase. The short summary of the RFC is
that it permits a type declaration to be one of several enumerated
types. For example, this is a potential signature for a multi-type map
routine:

 function map(callable $f, Array | Traversable $iterable);

I think what I am missing in the RFC is behaviour with scalar (weak)
typehints, and which type the variable in a class would be converted to.
Take for example:

This is not missing in the RFC; see the section called Weak Scalar
Types in Open Issues. However, it does not propose a solution. I have
been assured by a few people that it is possible and it is just
something that needs worked out.


Should the discussion phase lead to proposed conversion
rules in the RFC for scalar types or is it left for later?

Regards //Björn


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Union Types

[Levi Morrison]

> Also, just to clarify, if you combine this with the nullable types syntax
> (assuming prefix), then the nullable applies to the entire union type:
>
> ?int|float === int | float | null
>
> I do find the shorter syntax confusing TBH.
>
> Which actually leads me to a different thought: defining custom types and
> using them instead.
>
> I very much like Hacks type/newtype stuff, if we extended that to support
> union types:
>
> newtype Numeric = int|float;
>
> Then you end up with simply: ?Numeric as your type (it should be
> namespaced).
>
> You could further expand that with casting rules:
>
> newtype Numeric = int|float {
>   string as float;
>   bool as int;
> }
>
> or even go so far as:
>
> newtype Numeric = function($value): int|float {
>  if ($value typeof int) {
>  return $value;
>  }
>
> return (float) $value;
> }
>
> FTR: I hate that last one, just spitballing.
>
> - Davey
>
> P.S.
> if someone is willing to tackle the code for custom types I'm willing to
> write an RFC

This issue is addressed partially in the future scope section of the
RFC: https://wiki.php.net/rfc/union_types#long_type_expressions.

If both nullable and full union types are allowed I was planning on
disallowing the short-hand notation when using unions. As it isn't
that relevant at this stage it isn't noted in the RFCs anywhere.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Union Types

[Levi Morrison]

On Thu, Apr 14, 2016 at 3:12 AM, Derick Rethans  wrote:
> On Wed, 13 Apr 2016, Levi Morrison wrote:
>
>> As alluded to in an earlier email today[1] I am now moving the Union
>> Types RFC[2] to the discussion phase. The short summary of the RFC is
>> that it permits a type declaration to be one of several enumerated
>> types. For example, this is a potential signature for a multi-type map
>> routine:
>>
>> function map(callable $f, Array | Traversable $iterable);
>
> I think what I am missing in the RFC is behaviour with scalar (weak)
> typehints, and which type the variable in a class would be converted to.
> Take for example:

This is not missing in the RFC; see the section called Weak Scalar
Types in Open Issues. However, it does not propose a solution. I have
been assured by a few people that it is possible and it is just
something that needs worked out.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Union Types

[Lin Yo-An]

Derick Rethans  於 2016年4月14日 星期四寫道：

> On Thu, 14 Apr 2016, Lin Yo-An wrote:
>
> > On Thu, Apr 14, 2016 at 5:12 PM, Derick Rethans  > wrote:
> > I think type conversion shouldn't be done internally, implicitly.
> >
> > Implicit conversion leads more confusion in the language. when you
> > pass variables, you have to remember these conversion rules.
>
> Sorry, we already have this with our weak scalar types. You can't make
> union types not work with that.


>
Does Hack support weak type conversion?




-- 
Sent from Gmail Mobile

Re: [PHP-DEV] [RFC] Union Types

[Davey Shafik]

As mentioned in my nullable types comment, I think that we should NOT add a
Null type unless the nullable types RFC fails to pass. We should not
introduce both options, and I favor the nullable types over this for that
purpose.

With regards to Dericks comment on type conversion, I think either simply
casting to the first type always, or we're going to have to come up with
some potential complex rules.

For example, what if you have: int|float, and pass in (string) "0.5", if
those were separate types you'd get (int) 1, or (float) 0.5 respectively,
and as a user I'd definitely expect it to be passed in as (float) 0.5 —
maybe we cast to the least lossy type? So if you have int|float, then a
numeric string always becomes a float.

The flip-side is that if we just decide first-always then it's up to the
developer to just define it as "float|int" instead.

I think Derick has definitely hit upon the trickiest part of this.

Also, just to clarify, if you combine this with the nullable types syntax
(assuming prefix), then the nullable applies to the entire union type:

?int|float === int | float | null

I do find the shorter syntax confusing TBH.

Which actually leads me to a different thought: defining custom types and
using them instead.

I very much like Hacks type/newtype stuff, if we extended that to support
union types:

newtype Numeric = int|float;

Then you end up with simply: ?Numeric as your type (it should be
namespaced).

You could further expand that with casting rules:

newtype Numeric = int|float {
  string as float;
  bool as int;
}

or even go so far as:

newtype Numeric = function($value): int|float {
 if ($value typeof int) {
 return $value;
 }

return (float) $value;
}

FTR: I hate that last one, just spitballing.

- Davey

P.S.
if someone is willing to tackle the code for custom types I'm willing to
write an RFC

On Thu, Apr 14, 2016 at 2:25 AM, Derick Rethans  wrote:

> On Thu, 14 Apr 2016, Lin Yo-An wrote:
>
> > On Thu, Apr 14, 2016 at 5:12 PM, Derick Rethans  wrote:
> >
> > > I think what I am missing in the RFC is behaviour with scalar (weak)
> > > typehints, and which type the variable in a class would be converted
> to.
> > > Take for example:
> > >
> > > function foo(int|bool $var) { echo get_type( $var ), "\n"; }
> > >
> > > foo(5); I guess int(5)
> > > foo(false); I guess bool(false)
> > > foo(0.5);   It could be either int(1) or bool(true)
> > >
> > > And what if the hint would be "bool|int" ?
> >
> > I think type conversion shouldn't be done internally, implicitly.
> >
> > Implicit conversion leads more confusion in the language. when you
> > pass variables, you have to remember these conversion rules.
>
> Sorry, we already have this with our weak scalar types. You can't make
> union types not work with that.
>
> cheers,
> Derick
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] [RFC] Union Types

[Derick Rethans]

On Thu, 14 Apr 2016, Lin Yo-An wrote:

> On Thu, Apr 14, 2016 at 5:12 PM, Derick Rethans  wrote:
> 
> > I think what I am missing in the RFC is behaviour with scalar (weak)
> > typehints, and which type the variable in a class would be converted to.
> > Take for example:
> >
> > function foo(int|bool $var) { echo get_type( $var ), "\n"; }
> >
> > foo(5); I guess int(5)
> > foo(false); I guess bool(false)
> > foo(0.5);   It could be either int(1) or bool(true)
> >
> > And what if the hint would be "bool|int" ?
> 
> I think type conversion shouldn't be done internally, implicitly.
> 
> Implicit conversion leads more confusion in the language. when you 
> pass variables, you have to remember these conversion rules.

Sorry, we already have this with our weak scalar types. You can't make 
union types not work with that.

cheers,
Derick

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Union Types

[Lin Yo-An]

On Thu, Apr 14, 2016 at 5:12 PM, Derick Rethans  wrote:

> I think what I am missing in the RFC is behaviour with scalar (weak)
> typehints, and which type the variable in a class would be converted to.
> Take for example:
>
> function foo(int|bool $var) { echo get_type( $var ), "\n"; }
>
> foo(5); I guess int(5)
> foo(false); I guess bool(false)
> foo(0.5);   It could be either int(1) or bool(true)
>
> And what if the hint would be "bool|int" ?
>

I think type conversion shouldn't be done internally, implicitly.

Implicit conversion leads more confusion in the language. when you pass
variables, you have to remember these conversion rules.

type conversion should be done in the caller, that's why typed language
like C or C++ ask you to convert the type manually before you pass the
variable into a function.




-- 
Best Regards,

Yo-An Lin

Re: [PHP-DEV] [RFC] Union Types

[Derick Rethans]

On Wed, 13 Apr 2016, Levi Morrison wrote:

> As alluded to in an earlier email today[1] I am now moving the Union
> Types RFC[2] to the discussion phase. The short summary of the RFC is
> that it permits a type declaration to be one of several enumerated
> types. For example, this is a potential signature for a multi-type map
> routine:
> 
> function map(callable $f, Array | Traversable $iterable);

I think what I am missing in the RFC is behaviour with scalar (weak) 
typehints, and which type the variable in a class would be converted to. 
Take for example:

function foo(int|bool $var) { echo get_type( $var ), "\n"; }

foo(5); I guess int(5)
foo(false); I guess bool(false)
foo(0.5);   It could be either int(1) or bool(true)

And what if the hint would be "bool|int" ?

Although it's probably easy enough to solve in this case, the RFC should 
detail how type conversion works with the scalar types.

cheers,
Derick

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Union Types

[Lin Yo-An]

I think this will add more complexity to the runtime system. The type
hinting will be something we use to generate good JIT code, not just for
checking types.


Dmitry Stogov <dmi...@zend.com> 於 2016年4月14日 星期四寫道：

> The RFC doesn't say anything about support for multiple class names.
>
> function foo(A|B|C $x)
>
> Support for multiple classes would lead to complex implementation.
>
> Thanks. Dmitry.
>
> 
> From: Levi Morrison <morrison.l...@gmail.com <javascript:;>>
> Sent: Thursday, April 14, 2016 06:46
> To: internals
> Subject: [PHP-DEV] [RFC] Union Types
>
> As alluded to in an earlier email today[1] I am now moving the Union
> Types RFC[2] to the discussion phase. The short summary of the RFC is
> that it permits a type declaration to be one of several enumerated
> types. For example, this is a potential signature for a multi-type map
> routine:
>
> function map(callable $f, Array | Traversable $iterable);
>
> The second parameter `$iterable` is required to be of type Array or
> Traversable - any other type will error.
>
> I look forward to a helpful and meaningful discussion!
>
>   [1]: http://news.php.net/php.internals/92252
>   [2]: https://wiki.php.net/rfc/union_types
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-- 
Sent from Gmail Mobile

Re: [PHP-DEV] [RFC] Union Types

[Dmitry Stogov]

The RFC doesn't say anything about support for multiple class names.

function foo(A|B|C $x)

Support for multiple classes would lead to complex implementation.

Thanks. Dmitry. 


From: Levi Morrison <morrison.l...@gmail.com>
Sent: Thursday, April 14, 2016 06:46
To: internals
Subject: [PHP-DEV] [RFC] Union Types

As alluded to in an earlier email today[1] I am now moving the Union
Types RFC[2] to the discussion phase. The short summary of the RFC is
that it permits a type declaration to be one of several enumerated
types. For example, this is a potential signature for a multi-type map
routine:

function map(callable $f, Array | Traversable $iterable);

The second parameter `$iterable` is required to be of type Array or
Traversable - any other type will error.

I look forward to a helpful and meaningful discussion!

  [1]: http://news.php.net/php.internals/92252
  [2]: https://wiki.php.net/rfc/union_types

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC] Union Types

[Levi Morrison]

As alluded to in an earlier email today[1] I am now moving the Union
Types RFC[2] to the discussion phase. The short summary of the RFC is
that it permits a type declaration to be one of several enumerated
types. For example, this is a potential signature for a multi-type map
routine:

function map(callable $f, Array | Traversable $iterable);

The second parameter `$iterable` is required to be of type Array or
Traversable - any other type will error.

I look forward to a helpful and meaningful discussion!

  [1]: http://news.php.net/php.internals/92252
  [2]: https://wiki.php.net/rfc/union_types

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php