[RFC] Union Types v2 - Externals

On Wed, 4 Sep 2019 at 12:30, Arnold Daniels [email protected] 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

Le 4 sept. 2019 à 13:54, Dan Ackroyd [email protected] 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

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

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 .

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]

Hello,

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 .

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

Den tor. 5. sep. 2019 kl. 13.22 skrev Côme Chilliet [email protected]:

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
[email protected]

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

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 .