Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123807
Precedence: bulk
MIME-Version: 1.0
References: <2a6b92eb-d5e9-4a1a-9548-a068ac42ebd2@app.fastmail.com> <d06e5a04-9601-4af4-bdad-4f5e92bc5e18@app.fastmail.com>
In-Reply-To: <d06e5a04-9601-4af4-bdad-4f5e92bc5e18@app.fastmail.com>
Date: Tue, 25 Jun 2024 09:38:52 +0200
Message-ID: <CAPzBOBPZuiCrTaNi7s8bgtZbC5uZbfXKfcAc-BirZBEC3NWOFA@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 Tue, Jun 25, 2024 at 2:48=E2=80=AFAM Larry Garfield <larry@garfieldtech.=
com> wrote:
>
> On Thu, Jun 20, 2024, at 5:38 PM, Larry Garfield wrote:
>
> > To that end, we're looking for *very high level* feedback on this RFC:
> >
> > https://wiki.php.net/rfc/pattern-matching
>
> Hi folks.  Thank you to those who have offered feedback so far.  Based on=
 the discussion, here's what we're thinking of doing (still subject to chan=
ge, of course):
>
> * We're going to move `as` to future-scope.  There's enough weirdness aro=
und it that is independent of pattern matching itself that it will likely r=
equire its own discussion and RFC, and may or may not involve full pattern =
support.
>
> * Similarly, we're going to hold off on the weak-mode flag.  It sounds li=
ke the language needs to do more to fix the definition of "weak mode" befor=
e it's really viable. :-(  On the plus side, if the type system itself ever=
 adds support for a "coercion permitted" flag, patterns should inherit that=
 naturally, I think.
>
> * Array-application will also be pushed to future-scope.  Again, there's =
enough type-system tie in here that is tangential to patterns that we'll pi=
ck that fight later.
>
> * Ilija and I have discussed regex patterns a bit further, and it sounds =
like they=E2=80=99re going to be rather complicated to implement.  Even ass=
uming we agree on the syntax for it, it would be a substantial amount of co=
de to support.  (It=E2=80=99s not like types or literals or range where we =
can just drop something pre-existing into a new function.)  So we=E2=80=99r=
e going to hold off on this one for now, though it does seem like a high-pr=
iority follow-up for the future.  (Which doesn=E2=80=99t have to be us!)
>
> So let's not discuss the above items further at this point.
>
> * I'm going to do some additional research into other languages to see ho=
w they handle binding vs using variables from scope, and what syntax marker=
s they use and where.  Once we have a better sense of what is out there and=
 is known to work, we can make a more informed plan for what we should do i=
n PHP.  (Whether using a variable from scope in the pattern is part of the =
initial RFC is still an open question, but we do need to design it alongsid=
e the capture part to ensure they don't conflict.)  Stay tuned on this fron=
t.
>
> * We've removed the dedicated wildcard pattern, as it's equivalent to `mi=
xed`.  If there's interest, we're open to having a secondary vote to bring =
it back as a short-hand pattern.  It's trivial to implement and we don't ha=
ve strong feelings either way.
>
> * There's not been much discussion of range patterns.  Anyone want to wei=
gh in on those?
>
> * The placement of `is` on `match()` is still an open question.
>
> * No one has really weighed in on nested patterns for captured variables.=
  Any thoughts there?
>
> * I=E2=80=99ve seen a suggestion for capturing the =E2=80=9Crest=E2=80=9D=
 of an array when using =E2=80=A6  That=E2=80=99s an interesting idea, and =
we=E2=80=99ll explore it, though it looks like it may have some interesting=
 implications that push it to future scope.  It feels like a nice-to-have.
>
> Thanks all.
>
> --Larry Garfield

This morning, while thinking about "new Pattern($pattern)," it
occurred to me: why not create an OOP extension of patterns? It
wouldn't need an RFC or language changes and would allow the
development of patterns to the point where adding it to the core
language may be a no-brainer. You (and other users of it) would have a
pretty good idea of which patterns are actually important and useful
due to actually using them.

It's probably the "long way around" but at that point, you'd basically
just be pulling in the extension and discussing syntax as the behavior
would be well-defined and battle-tested.

Robert Landers
Software Engineer
Utrecht NL