Re: Unified ReflectionType methods

From: 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

« previous php.internals (#116194) next »