Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123718
Precedence: bulk
MIME-Version: 1.0
References: <2a6b92eb-d5e9-4a1a-9548-a068ac42ebd2@app.fastmail.com> <02ee8831-43a0-4857-886e-7f54fb42a99d@varteg.nz>
In-Reply-To: <02ee8831-43a0-4857-886e-7f54fb42a99d@varteg.nz>
Date: Fri, 21 Jun 2024 03:35:55 +0200
Message-ID: <CAB-Buja2B0_idnmjZFDNiQrGSRck-z-G7M1v8dNQ6ZyCf482OQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [Early Feedback] Pattern matching
To: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
From: andreas@dqxtech.net (Andreas Hennings)

> Ilija and I have been working on and off on an RFC for pattern matching since the early work on Enumerations.

I like what I see, a lot!
One quick thought that came to my mind, regarding objects:
Could we check method return values?

if ($x is Countable { count(): 0 }) ...
if ($p is Point { getX(): 3 }) ...
if ($x is Stringable { __toString(): 'hello' }|'hello') ...
while ($it is Iterator { valid(): true, current(): $value, next(): null }) ...

Maybe it goes too far.

For the variable binding, I noticed that we can overwrite the original variable:
$x is SomethingWrapper { something: $x }
In this case the bool return is not really needed.
For now this usage looks a bit unintuitive to me, but I might change
my mind and grow to like it, not sure.


For "weak mode" ~int, and also some other concepts, I notice that this
RFC is ahead of the type system.

E.g. should something like array<int> be added to the type system in
the future, or do we leave the type system behind, and rely on the new
"guards"?
public array $values is array<int>
OR
public array<int> $values

The concern here would be if in the future we plan to extend the type
system in a way that is inconsistent or incompatible with the pattern
matching system.

--- Andreas