Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115785
MIME-Version: 1.0
References: <CADK1yXLZzoOjjNcpZ5ZtV9kSNgw4=SW9G74o26eLdAYV5cDzAQ@mail.gmail.com>
 <CAEZPtU5STkockXmwYBQi0kd+rBtNkb9Z4UwvxMe7ozRSDTm8Ew@mail.gmail.com>
In-Reply-To: <CAEZPtU5STkockXmwYBQi0kd+rBtNkb9Z4UwvxMe7ozRSDTm8Ew@mail.gmail.com>
Date: Tue, 24 Aug 2021 02:55:20 -0700
Message-ID: <CAMrTa2EWdH5TrUU5R3fpkuDC_xmvfjMkwNhzOm=3EQucyrE1ZA@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Deleu <deleugyn@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000092357705ca4b22a3"
Subject: Re: [PHP-DEV] Guidelines for RFC post feature-freeze
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--00000000000092357705ca4b22a3
Content-Type: text/plain; charset="UTF-8"

On Mon, Aug 23, 2021 at 11:09 PM Pierre Joye <pierre.php@gmail.com> wrote:

>
> Many additions went through while being incomplete. It was documented
> so in the RFC but it does not make it a good thing. Many of them are
> indeed much needed and related to features (some) PHP users have been
> waiting for. Are they critical enough for the PHP usage to allow them
> in while knowing it is not complete? For almost all recent RFCS
> related to syntax, arguments/return types or properties, I don't think
> it justifies being added while being incomplete. It is not critical
> enough to the larger user base. It makes migration paths harder as
> well.
>

I just wanted to note that while this may be true, it's largely because RFC
authors cannot reasonably create and pass RFCs which:

1. Are too large or complex for voters to make an informed decision about.
2. Include too many aspects which are controversial or which have strongly
opposed viewpoints within the RFC voters.

RFCs which do either of these two things cannot pass, therefore all RFCs
which pass do neither. This will always result in RFCs which some people
view as "incomplete". It's not because the RFC authors, or even the voters,
forgot or "overlooked" something necessarily. It's simply a product of what
the PHP voters value. Voters value backwards compatibility; voters value a
strong use-case justification for a new feature; voters value consistency
between existing language features and new language features.

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
operator 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 implementation 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.

I would be very disappointed if I was able to successfully convince voters
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
incomplete because it only allows operator overload for objects instead of
globally or doesn't allow overloading of the null coalesce operator, for
instance.

As long as RFC authors must lobby voters to get a feature included, there
are features which will be cut in the interest of time, compromise,
complexity, and comprehension. I don't see how you avoid that without
abandoning the idea of voting altogether, which is something I'm sure we
all find value in.

Jordan

--00000000000092357705ca4b22a3--