Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123747
Date: Sat, 22 Jun 2024 02:38:22 +0000
To: Robert Landers <landers.robert@gmail.com>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [Early Feedback] Pattern matching
Message-ID: <v3oEjTijeI1IrOgEkasAWbm5f2SK8IfT4CS4VRaHvJPdMDkb9jmJb_KDXshJaYXssjnTeue-JWxudrQbvGYvhJPee_fOzXlOdAzyVUghGZ8=@gpb.moe>
In-Reply-To: <CAPzBOBO_8T2Gvpc4_4y-8v54YSNPnqpnivzsmLa2z93JtKP9WA@mail.gmail.com>
References: <2a6b92eb-d5e9-4a1a-9548-a068ac42ebd2@app.fastmail.com> <CAB_ngDjrZYC2ecsU9mgZ3kjMQnsy3PhYjLt8chPUZ=RDSwT9RQ@mail.gmail.com> <c66a9540-5701-4743-ac41-f3a34e784161@app.fastmail.com> <CAPzBOBO_8T2Gvpc4_4y-8v54YSNPnqpnivzsmLa2z93JtKP9WA@mail.gmail.com>
Feedback-ID: 96993444:user:proton
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: internals@gpb.moe ("Gina P. Banyard")

On Friday, 21 June 2024 at 23:58, Robert Landers <landers.robert@gmail.com>=
 wrote:
> As a user of PHP, this statement concerns me. I don't want any
> features rushed just because someone wants it "now" and thus end up
> with something feeling half-baked, missing important features or not
> completely thought through. I think it's pretty fair that this is a
> pretty big RFC (as in scope). Were it a PR under review, I might would
> ask you to break it up into smaller PRs because it's too big to
> discuss properly and were it smaller PR's we would probably arrive at
> a better solution than the giant PR.
>=20
> Perhaps, it might be worth breaking up into sub-RFC's (is that a
> thing?) where each pattern/feature can be discussed independently and
> the vote is whether or not it gets implemented in the parent RFC but
> has no binding on the parent RFC. Some things may be easy to discuss
> (such as type matching) but others might be longer (such as as, or
> arrays). But (and this is the key part) it wouldn't stop you from
> proceeding on the parent RFC, which is implementing pattern matching
> (in general) and any passed sub-RFC's.
>=20
> Maybe that could be a path forward? I don't know who makes the rules,
> but they're human rules and they can be anything -- in theory. Maybe
> "sub-RFC's" needs an RFC to define it, but that might let you move
> faster than a) trying to do everything all-at-once, and b) let
> hard-to-define parts of the overall feature get the time they deserve.

Breaking up an RFC into sub-RFCs which are each interdependent for the grea=
ter scope to be coherent doesn't make any sense.
An RFC being "large" is not an issue.
Moreover, this RFC is *already* a "sub-RFC" of the much larger in scope met=
a ADT RFC.

The scope of this RFC seems pretty moderate to me and well appropriate, and=
 part of this discussion is to establish what may be moved to later.
It is always possible to break down an RFC into new tiny RFCs about every s=
ingle possible design decision, it doesn't mean this should be done.
Writing RFCs, discussing them, and responding to feedback is extremely exha=
usting and time-consuming, as such the authors of an RFC are entitled to de=
cide what is in scope and what is not.
They also decide what can be moved out, and what cannot.
Part of being an RFC author is to *also* stand your ground on the scope and=
 design of your RFC while taking into account the feedback.


Best regards,

Gina P. Banyard