Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115784
MIME-Version: 1.0
References: <CADK1yXLZzoOjjNcpZ5ZtV9kSNgw4=SW9G74o26eLdAYV5cDzAQ@mail.gmail.com>
In-Reply-To: <CADK1yXLZzoOjjNcpZ5ZtV9kSNgw4=SW9G74o26eLdAYV5cDzAQ@mail.gmail.com>
Date: Tue, 24 Aug 2021 13:08:37 +0700
Message-ID: <CAEZPtU5STkockXmwYBQi0kd+rBtNkb9Z4UwvxMe7ozRSDTm8Ew@mail.gmail.com>
To: Deleu <deleugyn@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Guidelines for RFC post feature-freeze
From: pierre.php@gmail.com (Pierre Joye)

Hi Marco,

On Tue, Aug 24, 2021 at 3:49 AM Deleu <deleugyn@gmail.com> wrote:
>
> Hello everyone!
>
> We recently had the Nullable Intersection Types RFC process in an
> unconventional way starting a new RFC post feature freeze. If memory serves
> me right, another similar incident happened with the Attributes RFC which
> had a syntax that could not be implemented without a secondary RFC [1] and
> went through a secondary RFC which proposed a different syntax [2].
>
> [1] https://wiki.php.net/rfc/namespaced_names_as_token
> [2] https://wiki.php.net/rfc/attributes_v2
>
> I would like to gather opinion on a potential Policy RFC that would define
> some guidelines for such a process. As Nikita pointed out [3], the ability
> to refine new features is both important for the developer and undocumented
> for the PHP Project.
>
> In order to not be empty-handed, I started a gist that can be seen as the
> starting point for this discussion, available at
> https://gist.github.com/deleugpn/9d0e285f13f0b4fdcfc1d650b20c3105.
>
> Generally speaking, I'm first looking for feedback on whether this is
> something that deserves attention and an RFC or is it so rare that it's
> fine to leave it unchanged. If there is interest in moving forward, I would
> then also be interested in suggestions on things that should be
> included/excluded in the RFC.

It is a very good text, thank you!

It is also much needed, generally speaking. What I would add is about
what is allowed to begin with. I would rather restrict to fixes only.

The other issue, which is the one Nicolas suffered from, incomplete
addition to begin with. Incomplete in the sense of, "We add feature A,
but behaviors A1 and A2 are not supported and can be done later".

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.

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 and redo the implementation to support (hopefully) the
full features.

This is a path I dislike, I may have a different view on the big
picture, however I do think we rushed too many of these features too
early. A vote does not solve this problem given the limited amount of
votes we can see.

Best,
-- 
Pierre

@pierrejoye | http://www.libgd.org