Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115790
MIME-Version: 1.0
References: <CADK1yXLZzoOjjNcpZ5ZtV9kSNgw4=SW9G74o26eLdAYV5cDzAQ@mail.gmail.com>
 <CAEZPtU5STkockXmwYBQi0kd+rBtNkb9Z4UwvxMe7ozRSDTm8Ew@mail.gmail.com>
 <CAMrTa2EWdH5TrUU5R3fpkuDC_xmvfjMkwNhzOm=3EQucyrE1ZA@mail.gmail.com> <CAEZPtU65=Yfe-oQzxjDnYvccsrMLf9_cj9G6m8fKKEGELB=XDw@mail.gmail.com>
In-Reply-To: <CAEZPtU65=Yfe-oQzxjDnYvccsrMLf9_cj9G6m8fKKEGELB=XDw@mail.gmail.com>
Date: Tue, 24 Aug 2021 19:43:45 +0100
Message-ID: <CA+kxMuSq5WZCk-0R0eN6e0vfFAiD_Jr8pKMbBFyx1zJrDD8Z-w@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>, tobias.nyholm@gmail.com
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Guidelines for RFC post feature-freeze
From: Danack@basereality.com (Dan Ackroyd)

Pierre Joye wrote:
> Many additions went through while being incomplete.
> ...
> For almost all recent RFCS
> related to syntax, arguments/return types or properties, I don't think
> it justifies being added while being incomplete.

I think you are remembering how changes were made to PHP through rose
tinted glasses.

Pretty much all of the improvements to PHP's type system were
'incomplete' but they were still huge chunks of work, and some of them
only just got accepted.

Suggesting that (other) people need to do more work to satisfy the
level of quality you want in an RFC is a good way of stopping any
major progress from being achieved.

Seeing as a lot of RFCs that improve PHP's type system seem to be the
last RFC before someone decides to not bother contributing any more, I
strongly suggest not trying to make it more difficult to get
improvements made.

Pierre Joye wrote:
> A library or framework (main users of most of these features) may or
> may not implement the given addition, requiring say 8.1, and yet again
> require 8.2 ....
>
> What is one more year then? :)

If a library thinks a feature is 'incomplete' they can hold off using
it, while other people who think it's useful enough can use it
earlier.

After all, what is one more year then?

Pierre Joye wrote:
> I don't think we are not able to understand complex RFCs.

The intersection types RFC was pretty clear that it didn't support union ty=
pes.

This limitation could have been discussed as part of the RFC
discussion, and George would have explained his choice, namely that
implementing the RFC was going to be difficult and so he wanted to
limit the scope of the RFC*.

The fact that this limitation in scope apparently wasn't understood by
some people who apparently have strong feelings about it, suggests
that people don't always understand what is being discussed or voted
on.

Tobias Nyholm wrote:
> then the discussion and the vote should not consider =E2=80=9Cif it is to=
o late=E2=80=9D
> or =E2=80=9Cthis is rushed=E2=80=9D.

This is a really bad idea. Previously (but not recently), some of the
more heated RFC discussions moved from being about the RFC to being
about what are "right" and "wrong" reasons for voting.

That type of discussion very quickly descends into either name
calling, or people just refusing to take part in discussions.

If nothing else, how would you 'prove' that someone has voted for the
'wrong reason', and so needs to have their vote discounted?

cheers
Dan
Ack


* To be clear, the implementation was very difficult, and George spent
a huge amount of time on it. I suggest reviewing the implementation if
you aren't familiar with it:
https://github.com/php/php-src/commit/069a9fa5e4478c7044cb6432258cfe207d10a=
202
and definitely before saying that leaving out union types was an
'oversight'.