Re: Unified ReflectionType methods
| From: | Larry Garfield | Date: | Sun, 03 Oct 2021 14:26:05 +0000 |
| Subject: | Re: Unified ReflectionType methods | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-116194@lists.php.net to get a copy of this message | ||
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