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] Union Class Types (was Union Type (singular) straw man proposal)

[Stephen Reay]

> On 6 Sep 2019, at 14:37, Mike Schinkel  wrote:
> 
> Hi Stephen,
> 
> Thank you for taking the time to comment.
> 
>> It seems like you’re trying to allow for type conversions in a predictable 
>> manner,
> 
> Correct.
> 
>> but in a very different way than php already does that with built in types 
>> and interfaces
> 
> I proposed the best approach I could envision given the constraints of the 
> scenario.  
> 
> I elaborated in my first comment in my reply to Kalle; can you look at that 
> reply rather than have me repeat it?
> 
> OTOH, it would be wonderful it you could envision an approach that could use 
> types and/or interfaces and still have an approaching syntax when using 
> unions in an anonymous context when declaring parameters to a function or 
> method.
> 
> 
>> (__toString, the proposed __toArray, plus the various (de)serialiser options)
> 
> Unless I misunderstand, __toString() and __toArray() do not provide type 
> safety at the call site without casting.  
> 
> And since you cannot cast an object type in PHP — e.g. (Number)$myobject — it 
> seems magic methods are not suitable for task here?
> 
> Or can you envision a different alternative?
> 
> 
>> Your proposal seems to imply some kind of automatic method generation by the 
>> engine itself (or the examples are all missing that boilerplate??) which is 
>> very non obvious to me and I think would be to others too.
> 
> Hmm.  I was thinking of it being a lot like ArrayObject, Exception, Closure, 
> Generator,   in that you get methods built-in.
> 
> I wonder if the lack of obviousness would simply require a one-time learning, 
> or if it would be problematic for people on an ongoing basis?
> 
> Digressing, as I said in other messages I proposed this as much as a 
> discussion starter as anything.  So I am excited to discuss any alternate 
> approach others might suggest.
> 
>> From my perspective a more obvious solution for this type of thing would be 
>> a set of interfaces to define that a class can be safely cast to another 
>> type when used with typed properties/arguments/returns.
> 
> How would interfaces work in this context and for this use-case?  
> 
> I tried to leverage interfaces while writing the proposal as I know many 
> people prefer enhancements be packaged as interfaces, but I could not 
> envision how they could be applied to meet the goals here. 
> 
> And to reiterated my proposals goals they were to establish a concise syntax 
> that leverages existing language features for better type safety when 
> multiple types can correctly be passed as parameters and/or assigned to 
> properties.
> 
> 
>> (or magic methods to match __toString but I know they’re less preferred by 
>> some these days) 
> 
> Is it possible to get type safety from using __toString() in a manner as I am 
> struggling to envision one?
> 
>> tthat a class can be safely cast to another type when used with typed 
>> properties/arguments/returns.
> 
> What about for types where there is no syntax for casting?  Such as when one 
> ones to union instances of a class?
> 
> Anxious to hear your additional thoughts, if you have time.  
> 
> But either way, I very much appreciate the time you've taken to comment.
> 
> -Mike
> 
> 
>> On Sep 6, 2019, at 2:18 AM, Stephen Reay  wrote:
>> 
>> Hi Mike,
>> 
>> From a userland perspective I don’t really “get” your proposal.
>> 
>> It seems like you’re trying to allow for type conversions in a predictable 
>> manner, but in a very different way than php already does that with built in 
>> types and interfaces (__toString, the proposed __toArray, plus the various 
>> (de)serialiser options)
>> 
>> Your proposal seems to imply some kind of automatic method generation by the 
>> engine itself (or the examples are all missing that boilerplate??) which is 
>> very non obvious to me and I think would be to others too.
>> 
>> 
>> From my perspective a more obvious solution for this type of thing (and I’m 
>> not necessarily sure I’d use the feature myself to be honest) would be a set 
>> of interfaces (or magic methods to match __toString but I know they’re less 
>> preferred by some these days) to define that a class can be safely cast to 
>> another type when used with typed properties/arguments/returns.
>> 
>> 
>> Cheers
>> 
>> Stephen
> 

Hi Mike,

I did read your other replies before responding.


__toString is much older than type hints (and especially scalar type hints) in 
php and wasn’t really built for that purpose AFAIK, but in ‘weak’ mode (i.e. no 
strict_types=1) it would be invoked if the destination type specified a string. 
I was implying that this behaviour could be expanded both with other integer 
casting methods and to allow it to work in ’strict’ mode with an approach 
similar to how php works now, rather than suggesting that it works right now.


It’s true you can’t cast to an object (besides stdclass) - but again, my point 
was not so much that the functionality already exist, more so that your 

Re: [PHP-DEV] Union Class Types (was Union Type (singular) straw man proposal)

[Mike Schinkel]

Before responding to your points let me reiterate that I made the proposal as 
much to generate discussion on ideas that I was not seeing discussed as to see 
*my* proposal get selected and implemented.  So I like to think I won't be 
defensive about any criticism, and will be happy if the only thing that comes 
out of this is seeing these concepts considered that I did not think were being 
discussed.

> -- New magical methods that appear out of nowhere without an
> interface, e.g. ::type(), ::value(), ::setValue(), ::toXZY(). if these
> magical methods suddenly appear with may be varadic based on the value
> of the `types` setting, this is inconsistent to the rest of PHP.

That is a really good point, and something I agonized over.ai

(By your use of the term "variadic" I assume you are referring to the fact that 
toXxxx() functions would be defined based on the number of types listed after 
the types keyword?)

I thought about the potential to propose a base class but that would not 
address the toXxxx() functions.  And the same problem exists with an interface, 
right?

I thought about the potential to propose a `typedValue()` method to which you 
would pass the type you want to return, but types are not first-class in PHP 
and are only represented in strings such as you get when called gettype(). So 
that would mean the method could not be typed and thus effectively eliminate 
the whole point of the proposal.

Another issue with a base class and an interface is the desire to create a 
syntax that can be concise yet still leverage what already exists as much as 
possible as illustrated by these two examples from the proposal:

function showNumber(new class{types int|float} $number) {
   echo $number->value();
}
function showNumber2(int|float $number) {
   echo $number->value();
}

It would be very tedious is we had to do this:

function showNumber(new class extends UnionClass {types int|float} $number) {
   echo $number->value();
}

Or worse:

function showNumber(new class implements UnionInterface {types int|float; 
function type(){...}; function value(){...}; etc...} $number) {
   echo $number->value();
}

So, I will turn it around. How can we address this better than I proposed?  I 
sincerely did my best thus far, but I am sure it can be done better if only I 
could envision it.

(One idea would be for it to automatically implement a magic "UnionTypes" 
interface. Which would also need to be variadic.)


> -- There is no mention of what happens if there is multiple `types` in
> a definition.

 I don't understand this point.  Didn't my type example use int|float and then 
add string and \Foo\Bar?

I am sure you were referring to something else, but it is not clicking for me.


> -- Why is the syntax using | as a separator where all other decls is
> using a comma separated list?

Because that is the same syntax as both recent union types proposal used and 
also PHPDoc, for example:

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


And one of the reasons I think they may have chose that syntax is because I 
think using a comma here would potentially result in some developer confusion 
if not ambiguity, and to use pipes in the function parameter list but commas 
after the type keyword would be inconsistent:

function showNumber2(int,float $number) {
   echo $number->value();
}

That said, I am agnostic about that syntax; I picked what seemed to be the 
best.  When I started writing it I was planning to propose a new language 
feature called a union that could be declared like this:

union Number {
int;
float;
}

Or like this

function showNumber2(union{int;float} $number) {
   echo $number->value();
}


But as I wrote it up I realized that what I was proposing was simply a class 
with some special properties. To be clear the aspect of the proposal that is 
most fundamental is the auto-creation of the union class instance when a value 
is passed as a parameter or assigned to a property declare for that union class 
and the "variadic" methods that allow accessing the values in a type safe way,


> -- Nitpick The "types" decl doesn't use an ending semicolon in any of
> your examples
> -- Nitpick: Your examples in the "Accepting params into a union
> instance" section uses $this in a procedural function

Doh!  Copy paste error and my normal dependence on PhpStorm to ensure my syntax 
is always correct (but I can't have PhpStorm correct my proposed future syntax!)

Anyway, fixed. And thanks for catching.

> -- In the "Named Union equivalence to anonymous union" section I fail
> to see how Building2 can magically accept Building, this is based on
> properties and there is there is no mention of the ability to have (or
> not to have) multiple named unions as property types.

Well, would you accept "magic" as a valid answer?  :-D

Seriously though, I envision that PHP 

Re: [PHP-DEV] Union Class Types (was Union Type (singular) straw man proposal)

[Stephen Reay]

> On 6 Sep 2019, at 11:22, Mike Schinkel  wrote:
> 
> Hi Côme,
> 
>> This example is really confusing me more than anything else.
> 
> 
> Thank you very much for your feedback.  You illustrated perfectly why I 
> should not have produced that proposal in haste.
> 
> Your confusion was due to my first draft errors, which thanks to your 
> feedback I have hopefully had a chance to correct. I effectively rewrote and 
> extended the proposal which you should be able to find at the same URL:
> 
> https://gist.github.com/mikeschinkel/50aec7094f5643223d28674639f9f117 
> 
> 
> I would be greatly appreciative if you could give is a second look.
> 
> 
>> All in all I do not understand the benefits of this approach compared to 
>> Nikita’s RFC.
> 
> I have moved the benefits to the beginning of the document and expanded the 
> list I elaborate on. 
> 
> Hopefully they will be clear now?
> 
> 
> -Mike Schinkel
> 
> P.S. Someone graciously emailed me off list and mentioned that my comments 
> regarding Nikitia sounded like a criticism. If anyone else thought the same — 
> and especially Nikita — please understand I was attempting to praise him but 
> trying to do so in a humorous manner. 
> 
> As the person who emailed me made me realize, sometimes my humor may not 
> translate via a mailing list and especially not for those who are not native 
> English speakers. So I will do my best to avoid using humor on the list in 
> the future.  
> 
> To be clear, I am in awe of Nikita and both his abilities and efforts to 
> benefit the PHP community and greatly appreciate his efforts. I hope that 
> clarifies my earlier intent.
> 
> 
>> On Sep 5, 2019, at 4:51 AM, Côme Chilliet  wrote:
>> 
>> Why does the class Number in the example has a $number property and use 
>> $this->number->value() rather than $this->value() ?
>> 
>> What is the difference between its getNumber method and its value method?
>> 
>> Is $this->number and $this->number->number pointing the same object or is 
>> $this->number->number NULL?
>> 
>> This example is really confusing me more than anything else.
>> 
>> The "function showNumber" example is using $this->number instead of $number 
>> I think.
>> 
>> All in all I do not understand the benefits of this approach compared to 
>> Nikita’s RFC.
>> What does this allow you to do that you cannot do without?
>> 
>> Côme
> 

Hi Mike,

From a userland perspective I don’t really “get” your proposal.

It seems like you’re trying to allow for type conversions in a predictable 
manner, but in a very different way than php already does that with built in 
types and interfaces (__toString, the proposed __toArray, plus the various 
(de)serialiser options)

Your proposal seems to imply some kind of automatic method generation by the 
engine itself (or the examples are all missing that boilerplate??) which is 
very non obvious to me and I think would be to others too.


From my perspective a more obvious solution for this type of thing (and I’m not 
necessarily sure I’d use the feature myself to be honest) would be a set of 
interfaces (or magic methods to match __toString but I know they’re less 
preferred by some these days) to define that a class can be safely cast to 
another type when used with typed properties/arguments/returns.


Cheers

Stephen

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