Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115786
MIME-Version: 1.0
References: <CADK1yXLZzoOjjNcpZ5ZtV9kSNgw4=SW9G74o26eLdAYV5cDzAQ@mail.gmail.com>
 <CAEZPtU5STkockXmwYBQi0kd+rBtNkb9Z4UwvxMe7ozRSDTm8Ew@mail.gmail.com> <CAMrTa2EWdH5TrUU5R3fpkuDC_xmvfjMkwNhzOm=3EQucyrE1ZA@mail.gmail.com>
In-Reply-To: <CAMrTa2EWdH5TrUU5R3fpkuDC_xmvfjMkwNhzOm=3EQucyrE1ZA@mail.gmail.com>
Date: Tue, 24 Aug 2021 17:13:01 +0700
Message-ID: <CAEZPtU65=Yfe-oQzxjDnYvccsrMLf9_cj9G6m8fKKEGELB=XDw@mail.gmail.com>
To: Jordan LeDoux <jordan.ledoux@gmail.com>
Cc: Deleu <deleugyn@gmail.com>, 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: pierre.php@gmail.com (Pierre Joye)

Hi Jordan,

On Tue, Aug 24, 2021 at 4:55 PM Jordan LeDoux <jordan.ledoux@gmail.com> wro=
te:

> 1. Are too large or complex for voters to make an informed decision about=
.

This is the real problem. Also you are correct on the cause
(complexity of a topic), I don't think we are not able to understand
complex RFCs.

> 2. Include too many aspects which are controversial or which have strongl=
y opposed viewpoints within the RFC voters.

Incomplete implementation of a language construct is an order of
magnitude worse than having to wait a bit longer.

> RFCs which do either of these two things cannot pass, therefore all RFCs =
which pass do neither.

Together with others I wrote the RFC RFC along with a few required
after this. I fully grasp how hard it can be at times. However
language constructs are not some random extensions we can drop,
replace etc. They are basically there forever. And forever in my case
is as long as PHP exists. What is one more year then? :)

>  and new language features.

Which should be clearly complete to begin with, as much as possible. A
hard to find agreement is not a good enough reason to push a new
incomplete language feature, in my book. This is my only point.

> These are not bad things to value, and I don't see how you can expect RFC=
 authors to avoid proposing features which some may see as incomplete. My o=
perator overload RFC is something I've already put at least 100 hours into,=
 it's trimmed down to a very limited set of operators with restrictions on =
certain implementations, I still have many more hours of work left on the i=
mplementation in order to make the necessary changes to opcodes for it, and=
 it still will likely be something which there is significant resistance to=
. I might put in excess of 300-400 hours of work into this RFC only for it =
to be rejected because of differences of opinion on the feature.

You most likely will, and we are all grateful for that. It also shows
that such RFCs are not about a single individual. Language features
are better designed, proposed or implemented by a group of persons.
That's the tricky part but it may help a lot.

>
> I would be very disappointed if I was able to successfully convince voter=
s of the value of my contribution, address the concerns that were presented=
 and find good compromises, and then be told that my work was faulty and in=
complete because it only allows operator overload for objects instead of gl=
obally or doesn't allow overloading of the null coalesce operator, for inst=
ance.

I cannot say anything about it as I did not go through it deeply.
However, yes, I would rather vote no on operator overloading not being
fully documented in the RFC. I could imagine not every single case
could go in the 1st round. While operators overloading add enough
complexity already without having to think about where it will work
and where not, as an end user.

But the roadmap must then be clear, implementation etc. The idea of
saying "let see later" is not a good way to accept language changes.

Best,
--=20
Pierre

@pierrejoye | http://www.libgd.org