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

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

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

> 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

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

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,

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

> 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

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

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

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

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

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

> 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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

> > 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

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

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 >

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

> > 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

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

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

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

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

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

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. >

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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 ,

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

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

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

> 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

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

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

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

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

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

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 -

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

- 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

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

> > 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

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

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

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

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: > >

[PHP-DEV] [RFC] Union Types v2

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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: > > > >

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

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 ),

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

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

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

; > 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:

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

, 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 e

[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: