Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123740
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-522-ga39cca1d5-fm-20240610.002-ga39cca1d
Precedence: bulk
MIME-Version: 1.0
Message-ID: <de771d13-eba8-4904-9c92-233fb503d41d@app.fastmail.com>
In-Reply-To: <7ec12de5-b2f7-481c-acca-1b38f5be7deb@mabe.berlin>
References: <2a6b92eb-d5e9-4a1a-9548-a068ac42ebd2@app.fastmail.com>
 <7ec12de5-b2f7-481c-acca-1b38f5be7deb@mabe.berlin>
Date: Fri, 21 Jun 2024 18:03:25 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [Early Feedback] Pattern matching
Content-Type: text/plain
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Jun 21, 2024, at 3:57 PM, Marc Bennewitz wrote:

>> Thank you all for your participation.

> Is is already a really nice RFC, even if not finished yet. Also haven't 
> fully read it yet.
> Thank you for all your work and time put into it!
>
> I do have some questions:
>
> * For the generics-like pattern I do agree with the others that this 
> might be dangerous for the future if we (hopefully) are going at it.

I'm unsure.  As noted in the introduction, a pattern may look like some other construct but is not that construct.  So `$a is [1, 2, 3]` is not actually creating an array, for example.  That means using array<int> should not, at the engine level, cause any conflict with future generics implementations, should they ever materialize.  It's really just a shorthand for

foreach ($arr as $v) if (!is_int($vl)) throw \Exception;

Now, whether or not it would be confusing for the user is a different question.  Array-application is not part of the critical path, so if the consensus is to hold off on that for now, we can.  (Answering that question is what this thread is for.)

> * Capturing values out of a pattern and binding them to variables if matched.
>
> Where this is very helpful especially with `match`, from the syntax I 
> would read it as a condition only.
>
>     $p is Point {x: 3, y: $y}; // read as $p->y === $y but it's $y = $p->y
>
> But this is described differently
>
>     $p is Point {y: 37, x:@($x)};
>
>
> I think it would be more readable on switching the logic (somehow). like:
>
>     $p is Point {x: 3, y: $y}; // $p->y === $y
>     $p is Point {x: 3, y:=> $y}; // $y = $p->y 

There was a bug in that example that I fixed this morning.  It's now:

$p is Point {x: 3, y: $y}; // If $p->x === 3, bind $p->y to $y and return true.

Please ignore the old buggy version. :-)

> * Regex pattern
>
> This one is interesting as well ... but I would expect native regex 
> syntax first before introducing it as part of a different RFC. Similar 
> as generics.

Named capture groups are already part of regex syntax, just not often used.  The example is not introducing anything new there.  (Although Ilija tells me it may be hard to implement, so it may get postponed anyway.  TBD.)

> Following up I would expect something like this:
>
>     $re = /.*/;  // RegEx object
>     $matches = $re->match($v); // preg_match
>     $v is $re; // used in pattern matching
>
> which opens up another question: Could we have an interface allowing 
> objects to match in a specific way?
>
>     interface Matchable {
>         public function match(mixed $value): bool;
>     }

Oh my.  I'm not sure how feasible that would be, or what the implications would be.  Definitely future-scope at best. :-)

--Larry Garfield