Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116194
User-Agent: Cyrus-JMAP/3.5.0-alpha0-1322-g921842b88a-fm-20210929.001-g921842b8
Mime-Version: 1.0
Message-ID: <861db10e-a407-40d1-9346-af2fd634e47e@www.fastmail.com>
In-Reply-To: 
 <DM5PR17MB14812ACD139468310B110EB3F9AC9@DM5PR17MB1481.namprd17.prod.outlook.com>
References: 
 <CAB-BujZrArtUZa7taTKwSRg70eYsyM8hUO=iJj3bmo7mtw-XmA@mail.gmail.com>
 <DM5PR17MB14812ACD139468310B110EB3F9AC9@DM5PR17MB1481.namprd17.prod.outlook.com>
Date: Sun, 03 Oct 2021 16:26:05 +0200
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] Unified ReflectionType methods
From: larry@garfieldtech.com ("Larry Garfield")

On Sat, Oct 2, 2021, at 4:37 PM, tyson andre wrote:
> Hi Andreas,
>
>> Hello list,
>> I would like to propose new methods for ReflectionType, that would
>> allow treating ReflectionNamedType and ReflectionUnionType in a
>> unified way.
>> This would eliminate the need for if (.. instanceof) in many use cases.
>> 
>> Some details can still be discussed, e.g. whether 'null' should be
>> included in builtin type names, whether there should be a canonical
>> ordering of type names, whether we should use class names as array
>> keys, etc.
>> ... 
>> What do you think?
>
> Relatedly, I also had different ideas lately about new methods for 
> ReflectionType, though of a different form.
>
> 1. To simplify code that would check `instanceof` for all current and 
> future types such as `never` and `mixed` and intersection types
>     `ReflectionType->allowsValue(mixed $value, bool $strict = true): 
> bool`
>
>    Maybe also `allowsClass(string $className, bool $strict = true): 
> bool` to avoid needing to instantiate values (weak casting allows 
> Stringable->string).
> 2. To simplify code generation, e.g. in mocking libraries for unit 
> testing: `ReflectionType->toFullyQualifiedString(): string` (e.g. 
> `\A|\B`) (may need to throw ReflectionType for types that can't be 
> resolved, e.g. `parent` in reflection of traits, keep `static` as is)
>
>     (The raw output of `__toString()` isn't prefixed with `\` (e.g. 
> `A&B`) and can't be used in namespaces
>
> The fact that both intersection and union types (and possibility of 
> union types of full intersection types)
> make it hard for me to believe that getBuiltinTypes and 
> getBuiltinClasses would be used correctly when used.
>
> Thanks,
> Tyson

I think at this point I prefer this approach, for the reasons George mentioned.  "Here's a value, is it going to work if I pass it to this type check?" is a nice and generic operation that would extend gracefully as the type system expands.

It also dovetails with the pattern matching that Ilija and I had been working on, although that's now stalled as he is unavailable for personal reasons.  That is also largely a "here's a type def, does this value match it?" check, but with a few extra bits.  (If someone wants to take over the code side of that, please let me know.  It's over my head to implement but we have a fairly-complete design and the code is partially done.)

--Larry Garfield