Re: [DISCUSSION] ReflectionType::accepts

Hi Nikita I was indeed thinking about the former: acceptsValue; but I would excpect that if the concrete value is a subtype of the current type, the fuction would also return true. What I'm basically interested in: will this method throw a type error when I pass this value? In other words: "will this method accept this value?" Is that in line with your view on acceptsValue? Kind regards Brent > On 29 Jan 2021, at 10:33, Nikita Popov <nikita.ppv@gmail.com> wrote: > > On Fri, Jan 29, 2021 at 9:15 AM Brent Roose <brendt@stitcher.io > <mailto:brendt@stitcher.io>> wrote: > Hi Internals > > Since the addition of union types, it has become a little more cumbersome to determine whether > a given parameter type accepts specific input. Personally I've been reusing this code blob in > several places because of it: > > ``` > /** @var \ReflectionNamedType[] $types */ > $types = match ($type::class) { > ReflectionUnionType::class => $type->getTypes(), > ReflectionNamedType::class => [$type], > }; > > foreach ($types as $type) { > if (! is_subclass_of($type->getName(), ShouldBeStored::class)) { > continue; > } > > // … > } > ``` > > I wonder whether we would discuss adding a method on ReflectionType that accepts any given > input, and tells you whether that input is valid for that type or not. I was thinking about > ReflectionType::accepts(string|object $input): bool but we could > discuss another name. With it, the above example could be refactored like so: > > ``` > if (! $type->accepts(ShouldBeStored::class)) { > return; > } > > // … > ``` > > I believe this method should accept both class names and objects to be consistent with the > existing reflection API. It would also work with intersection types, if they are to be added some > day. > > What do you think? > > Kind regards > Brent > > There's two possible notions of what "accepts" does: > > * acceptsValue(), whether a given value satisfies the type. Probably needs a flag to determine > whether strict_types semantics should be used or not. > > * isSubTypeOf(), whether a given type satisfies the type in a subtyping relationship. > > You seem to be mixing these two up into one concept, even though they are quite different. > Which is the one you actually need? (I am much more open to providing the former than the latter.) > > Nikita