# [RFC] Union Types v2

- Thread: https://externals.io/message/106844
- Original archive: https://news-web.php.net/php.internals/106844
- Started by Nikita Popov on 2019-09-04T08:26:09+00:00
- Messages: 74
- RFC: Union Types (Declined) — https://externals.io/rfc/union_types.md
- Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/106844.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #106844 — Nikita Popov — 2019-09-04T08:26:09+00:00

URL: https://externals.io/message/106844#106844

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/0000-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&Levi (
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

---

## #106845 — Marco Pivetta — 2019-09-04T09:15:08+00:00

URL: https://externals.io/message/106844#106845 · In reply to: #106844

Hey Nikita,



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

---

## #106846 — Aegir Leet — 2019-09-04T09:36:19+00:00

URL: https://externals.io/message/106844#106846 · In reply to: #106844

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.



> 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/0000-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&Levi (
> 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

---

## #106847 — Nicolas Grekas — 2019-09-04T09:58:53+00:00

URL: https://externals.io/message/106844#106847 · In reply to: #106844

>
> https://github.com/nikic/php-rfcs/blob/union-types/rfcs/0000-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

---

## #106848 — Matthew Brown — 2019-09-04T11:20:35+00:00

URL: https://externals.io/message/106844#106848 · In reply to: #106847

- 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



> > […]
> 
> 
> 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

---

## #106849 — Arnold Daniels — 2019-09-04T11:30:03+00:00

URL: https://externals.io/message/106844#106849 · In reply to: #106847

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]

---

## #106850 — Peter Bowyer — 2019-09-04T11:45:43+00:00

URL: https://externals.io/message/106844#106850 · In reply to: #106849

On Wed, 4 Sep 2019 at 12:30, Arnold Daniels <arnold.adaniels.nl@gmail.com>
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

---

## #106851 — Dan Ackroyd — 2019-09-04T11:54:31+00:00

URL: https://externals.io/message/106844#106851 · In reply to: #106847

On Wed, 4 Sep 2019 at 10:59, Nicolas Grekas
<nicolas.grekas+php@gmail.com> 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

---

## #106854 — Claude Pache — 2019-09-04T13:23:35+00:00

URL: https://externals.io/message/106844#106854 · In reply to: #106851

> Le 4 sept. 2019 à 13:54, Dan Ackroyd <danack@basereality.com> a écrit :
> 
> > […]
> 
> 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

---

## #106868 — come@opensides.be — 2019-09-05T09:39:58+00:00

URL: https://externals.io/message/106844#106868 · In reply to: #106844

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

---

## #106870 — Brent — 2019-09-05T10:04:55+00:00

URL: https://externals.io/message/106844#106870 · In reply to: #106868

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

> Le mercredi 4 septembre 2019, 10:26:09 CEST Nikita Popov a écrit :
> > […]
>
> Huge "no" from me on using github for discussing RFCs.
>
> Huge "yes" on the RFC content.
>
> > […]
>
> 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

---

## #106871 — come@opensides.be — 2019-09-05T10:21:29+00:00

URL: https://externals.io/message/106844#106871 · In reply to: #106870

Le jeudi 5 septembre 2019, 12:04:55 CEST Brent a écrit :
> > […]
> 
> 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

---

## #106872 — Joe Watkins — 2019-09-05T10:50:48+00:00

URL: https://externals.io/message/106844#106872 · In reply to: #106871

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

---

## #106873 — Rowan Tommins — 2019-09-05T11:08:21+00:00

URL: https://externals.io/message/106844#106873 · In reply to: #106871

> Le jeudi 5 septembre 2019, 12:04:55 CEST Brent a écrit :
> > […]
> 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]

---

## #106874 — come@opensides.be — 2019-09-05T11:27:10+00:00

URL: https://externals.io/message/106844#106874 · In reply to: #106872

Le jeudi 5 septembre 2019, 12:50:48 CEST Joe Watkins a écrit :
> > […]
> 
> 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.

> > […]
> 
> 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

---

## #106875 — Mark Randall — 2019-09-05T12:05:40+00:00

URL: https://externals.io/message/106844#106875 · In reply to: #106873

> 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

---

## #106876 — Dan Ackroyd — 2019-09-05T12:07:28+00:00

URL: https://externals.io/message/106844#106876 · In reply to: #106874

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

---

## #106877 — George Peter Banyard — 2019-09-05T13:13:56+00:00

URL: https://externals.io/message/106844#106877 · In reply to: #106876

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

---

## #106878 — Brent — 2019-09-05T13:29:21+00:00

URL: https://externals.io/message/106844#106878 · In reply to: #106877

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

> 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

---

## #106879 — Rowan Tommins — 2019-09-05T13:47:07+00:00

URL: https://externals.io/message/106844#106879 · In reply to: #106878

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

---

## #106880 — Dan Ackroyd — 2019-09-05T13:49:30+00:00

URL: https://externals.io/message/106844#106880 · In reply to: #106878

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

---

## #106881 — Rowan Tommins — 2019-09-05T15:17:01+00:00

URL: https://externals.io/message/106844#106881

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

---

## #106882 — Peter Kokot — 2019-09-05T21:45:18+00:00

URL: https://externals.io/message/106844#106882 · In reply to: #106871

Hello,


>
> Le jeudi 5 septembre 2019, 12:04:55 CEST Brent a écrit :
> > […]
>
> 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

---

## #106883 — Benjamin Morel — 2019-09-05T21:45:21+00:00

URL: https://externals.io/message/106844#106883 · In reply to: #106881

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

---

## #106884 — Mark Randall — 2019-09-06T01:03:23+00:00

URL: https://externals.io/message/106844#106884 · In reply to: #106883

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

---

Next page: https://externals.io/message/106844.md?page=2