Currently there is no (documented) way to directly create a
\ReflectionType object.
The class has no documented constructor.
I propose that static factory methods shall be added for this purpose.
This will be useful for code that wants to dynamically create and pass
around reflection type objects.
/** @var bool $allowsNull */
$t1 = \ReflectionType::fromBuiltinType('string', $allowsNull);
$t2 = \ReflectionType::fromClassName(\stdClass::class, $allowsNull);
assert(true === $t1->isBuiltin());
assert(false === $t2->isBuiltin());
assert('string' === $t1->getName());
assert(\stdClass::class === $t2->getName());
To be discussed:
- method names
- Whether to return ReflectionNamedType or ReflectionType or something else.
(I don't find ReflectionNamedType documented in
http://php.net/manual-lookup.php?pattern=ReflectionNamedType)
What's the use-case for creating a userland ReflectionType instance,
besides mocking the reflection API itself?
Consider that the subclassing in userland already provides an easy way to
perform these operations (although ugly):
https://github.com/Roave/BetterReflection/blob/2.0.1/src/Reflection/Adapter/ReflectionType.php
Not trying to drag down your proposal, but as you can see this is already
being done and works very well and is very well tested for BC compliance
(should new methods land into ReflectionType).
Also, I'd add that a the proposed API should accept
InternalType|ReflectionClass|null, and not string (separate named
constructors would be best) which is basically the reason for most
hair-pulling around the PHP lang.
A small InternalType VO that throws on InternalType::fromString() : self would be extremely beneficial to avoid the continuously growing list
of edge cases and additions required to accommodate for new internal types
being added to the language.
Currently there is no (documented) way to directly create a
\ReflectionType object.
The class has no documented constructor.
I propose that static factory methods shall be added for this purpose.
This will be useful for code that wants to dynamically create and pass
around reflection type objects.
/** @var bool $allowsNull */
$t1 = \ReflectionType::fromBuiltinType('string', $allowsNull);
$t2 = \ReflectionType::fromClassName(\stdClass::class, $allowsNull);
assert(true === $t1->isBuiltin());
assert(false === $t2->isBuiltin());
assert('string' === $t1->getName());
assert(\stdClass::class === $t2->getName());
To be discussed:
- method names
- Whether to return ReflectionNamedType or ReflectionType or something else.
(I don't find ReflectionNamedType documented in
http://php.net/manual-lookup.php?pattern=ReflectionNamedType)
What's the use-case for creating a userland
ReflectionTypeinstance,
besides mocking the reflection API itself?
Consider that the subclassing in userland already provides an easy way to
perform these operations (although ugly):
https://github.com/Roave/BetterReflection/blob/2.0.1/src/Reflection/Adapter/ReflectionType.php
You are right.
And it does not even need BetterReflection library, it only needs one
single class which can also be defined locally.
It only needs $this->name, $this->allowsNull and $this->isBuiltin as
private properties.
(nothing against the library, just in case someone only needs this one feature)
Still, I think having a documented native constructor and/or static
factories would make this API more complete.
Without this, it seems like someone walked away from a construction site.
Also, inheriting from core reflection classes, I imagine always
carries some baggage.
(as opposed to implementing an interface)
Not trying to drag down your proposal, but as you can see this is already
being done and works very well and is very well tested for BC compliance
(should new methods land intoReflectionType).Also, I'd add that a the proposed API should accept
InternalType|ReflectionClass|null, and notstring(separate named
constructors would be best) which is basically the reason for most
hair-pulling around the PHP lang.A small
InternalTypeVO that throws onInternalType::fromString() : self
would be extremely beneficial to avoid the continuously growing list of edge
cases and additions required to accommodate for new internal types being
added to the language.Currently there is no (documented) way to directly create a
\ReflectionType object.
The class has no documented constructor.I propose that static factory methods shall be added for this purpose.
This will be useful for code that wants to dynamically create and pass
around reflection type objects./** @var bool $allowsNull */
$t1 = \ReflectionType::fromBuiltinType('string', $allowsNull);
$t2 = \ReflectionType::fromClassName(\stdClass::class, $allowsNull);assert(true === $t1->isBuiltin());
assert(false === $t2->isBuiltin());assert('string' === $t1->getName());
assert(\stdClass::class === $t2->getName());To be discussed:
- method names
- Whether to return ReflectionNamedType or ReflectionType or something else.
(I don't find ReflectionNamedType documented in
http://php.net/manual-lookup.php?pattern=ReflectionNamedType)