Re: [Early Feedback] Pattern matching

From: Date: Fri, 21 Jun 2024 18:03:25 +0000
Subject: Re: [Early Feedback] Pattern matching
References: 1 2  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
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


Thread (79 messages)

« previous php.internals (#123740) next »