Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123749
Precedence: bulk
MIME-Version: 1.0
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>
 <v3oEjTijeI1IrOgEkasAWbm5f2SK8IfT4CS4VRaHvJPdMDkb9jmJb_KDXshJaYXssjnTeue-JWxudrQbvGYvhJPee_fOzXlOdAzyVUghGZ8=@gpb.moe>
In-Reply-To: <v3oEjTijeI1IrOgEkasAWbm5f2SK8IfT4CS4VRaHvJPdMDkb9jmJb_KDXshJaYXssjnTeue-JWxudrQbvGYvhJPee_fOzXlOdAzyVUghGZ8=@gpb.moe>
Date: Sat, 22 Jun 2024 07:43:44 +0200
Message-ID: <CAPzBOBNLb+vTwMW1Juh2xBiXvTABn_fVYjD_EvU9Obcq8oHXxw@mail.gmail.com>
Subject: Re: [PHP-DEV] [Early Feedback] Pattern matching
To: "Gina P. Banyard" <internals@gpb.moe>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: landers.robert@gmail.com (Robert Landers)

On Sat, Jun 22, 2024 at 4:38=E2=80=AFAM Gina P. Banyard <internals@gpb.moe>=
 wrote:
>
> On Friday, 21 June 2024 at 23:58, Robert Landers <landers.robert@gmail.co=
m> 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.
> >
> > 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.
> >
> > 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 gr=
eater 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 m=
eta ADT RFC.
>
> The scope of this RFC seems pretty moderate to me and well appropriate, a=
nd 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=
 single possible design decision, it doesn't mean this should be done.
> Writing RFCs, discussing them, and responding to feedback is extremely ex=
hausting and time-consuming, as such the authors of an RFC are entitled to =
decide 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 a=
nd design of your RFC while taking into account the feedback.
>
>
> Best regards,
>
> Gina P. Banyard

Hey Gina,

Sorry, I wasn't exactly clear what I meant on scope. I wasn't
necessarily meaning the feature/RFC, but rather the scope of the
conversation. I count at least 12 new types of syntax here (possibly
more that I missed), and I would be surprised if some of them were to
pass in isolation; but as you said, people want the feature so they'll
pass the RFC and we'll get weird symbols that are near meaningless all
over our code. That's my concern here, not so much the feature. I want
the feature too, but there are some weird things in here that could
use longer discussions but shouldn't hold the overall feature back.

Robert Landers
Software Engineer
Utrecht NL