Re: Pattern matching details questions
| From: | Larry Garfield | Date: | Tue, 04 Feb 2025 21:16:57 +0000 |
| Subject: | Re: Pattern matching details questions | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-126288@lists.php.net to get a copy of this message | ||
On Tue, Feb 4, 2025, at 1:14 PM, Marc Bennewitz wrote:
> On 04.02.25 08:51, Rob Landers wrote:
>>
>>
>> On Tue, Feb 4, 2025, at 05:31, Larry Garfield wrote:
>>> Hi folks. Ilija is still working on the implementation for the pattern matching RFC,
>>> which we want to complete before proposing it officially in case we run into implementation
>>> challenges.
>>>
>>> Such as these, on which we'd like feedback on how to proceed.
>>> [1]
>>> https://github.com/Crell/php-rfcs/blob/master/pattern-matching/research.md
>>>
>>> --
>>> Larry Garfield
>>> larry@garfieldtech.com
>>>
>>
>> Hey Larry,
>>
>> Instead of symbols, why not use words?
>>
>> We already have &&, but it looks like this uses & instead, which is a
>> bitwise-and. But the language does have “and” as a keyword. So instead of:
>>
>> $value is int & &$x
>>
>> It would be:
>>
>> $value is int and &$x
>>
>> Which removes the confusion you mentioned before (also for someone like me who uses
>> bitwise-and quite a bit).
>>
>> — Rob
Patterns are deliberately designed as a superset of existing DNF types. You can already have a type
of Foo&Bar, so we want the pattern for "instanceof Foo || instanceof Bar" to be the
same. That means & and | for conjunctions is necessary. Also supporting "and" and
"or" would technically be possible, but wouldn't resolve the issue (since & would
still be needed either way) and would just add more complication, confusion, and inconsistency. I
don't think that's viable.
> Is it possible to use the already added "is", like:
>
> $arr is ['a' => $a, 'b' => is $b]
Would that inner "is" be capturing $b, or injecting $b? It just pushes the same question
down a level, and with an LL(1) parser we cannot tell what context we're in. (If we could,
there would be no problem.)
> Or, to use the already known uniform variable syntax "{$var}", like:
>
> $arr is ['a' => $a, 'b' => {$b}]
That looks like it could be confused with a property pattern, assuming we end up doing that for part
1. In which case, is that "index b maps to an object with one property, and bind that
property" or "index b maps to an object with one property, and that property should be the
value of $b"? Or "index b maps to the value of $b"? That doesn't seem any less
confusing, for the engine or human.
--Larry Garfield