Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123745
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>
In-Reply-To: <c66a9540-5701-4743-ac41-f3a34e784161@app.fastmail.com>
Date: Sat, 22 Jun 2024 00:58:05 +0200
Message-ID: <CAPzBOBO_8T2Gvpc4_4y-8v54YSNPnqpnivzsmLa2z93JtKP9WA@mail.gmail.com>
Subject: Re: [PHP-DEV] [Early Feedback] Pattern matching
To: Larry Garfield <larry@garfieldtech.com>
Cc: 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 Fri, Jun 21, 2024 at 9:33=E2=80=AFPM Larry Garfield <larry@garfieldtech.=
com> wrote:
>
> On Fri, Jun 21, 2024, at 3:35 PM, Brandon Jackson wrote:
> >> Ilija and I have been working on and off on an RFC for pattern matchin=
g since the early work on Enumerations.  A number of people have noticed an=
d said they're looking forward to it.
> >
> > Hi Larry, I have definitely been looking forward to this. Perhaps more
> > so than property hooks and avis.
> >
> >> By "very high level," I mean, please, do not sweat specific syntax det=
ails right now.  That's a distraction.  What we're asking right now is "whi=
ch of these patterns should we spend time sweating specific syntax details =
on in the coming weeks/months?"  There will be ample time for detail bikesh=
edding later, and we've identified a couple of areas where we know for cert=
ain further syntax development will be needed because we both hate the curr=
ent syntax. :-)
> >
> > I think that a lot of this would be best broken up. Although much of
> > it is aimed towards the same general idea, a lot of the pieces have
> > specific use cases and special syntax additions. Overall I think this
> > rfc should be simplified to just pattern matching with the `is`
> > keyword with the patterns limited to what can be declared as property
> > types (DNF types) and future scoping everything else. Maybe possibly
> > with the addition of 1 or 2 of the top requested `is` pattern matching
> > capabilities as secondary votes.
>
> To give more context, as noted, this is a stepping stone toward ADTs.  An=
ything that is on the "hot path" for ADT support I would consider mandatory=
, so trying to split it up will just take more time and effort.  That inclu=
des the object pattern and match support, and the object pattern realistica=
lly necessitates literals.  Variable binding would also be almost mandatory=
 for ADTs.  I'm very reluctant to push off anything in that hot path, as ev=
ery RFC has additional overhead, and I'm all volunteer time. :-)
>

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.

>
> --Larry Garfield

Robert Landers
Software Engineer
Utrecht NL