On Mon, Jul 4, 2016 at 10:51 AM, Björn Larsson
<bjorn.x.lars...@telia.com> wrote:
> Den 2016-06-30 kl. 23:57, skrev Nikita Popov:
>>
>> On Thu, Jun 30, 2016 at 6:06 PM, Levi Morrison <le...@php.net> wrote:
>>
>>> The RFC for improving ReflectionType[1] is now in voting phase. The
>>> voting
>>> window is June 30th through July 8th. I have not finished the patch but
>>> I'll have it done before the end of voting.
>>>
>>> [1]: https://wiki.php.net/rfc/ReflectionTypeImprovements
>>
>>
>> Replying on-list as multiple people asked:
>>
>> I'm voting against this RFC, because it introduced not only the
>> ReflectionNamedType class (which is reasonable), but also the
>> ReflectionClassType class (which is not).
>>
>> My main objection to ReflectionClassType is that it is autoloading
>> dependent (*). Something like getReturnType() on a class type hint will
>> either return a ReflectionClassType if the class can be loaded, or a
>> ReflectionNamedType if it can't. I think this is confusing and I'm sure
>> that this will lead to broken code: For example, people will try to use
>> "$type instanceof ReflectionClassType" to check whether something is a
>> class type hint, while the currently correct way, which works
>> independently
>> of class loading, is to check isBuiltin() instead.
>>
>> I don't think that most consumers of ReflectionType are interested in
>> obtaining a ReflectionClass for the type hint anyway (which is the only
>> functionality that ReflectionClassType provides), and if necessary this
>> can
>> be easily done in userland. There is no need to over-complicate the
>> ReflectionType functionality in this manner, especially with the proposed
>> semantics.
>>
>> Nikita
>>
> Maybe one should split the vote into separate for each function.
> I mean pity if vote fails because one function is not attractive while
> the other one is...
>
> What do you think?
>
> Regards //Björn Larsson
I think that it's disappointing that I received no feedback on this
RFC at all and yet have this ratio of votes in the negative.
I'll take this opportunity to share a portion of a conversation I had
with Nikita that demonstrates why ReflectionClassType is actually
useful:
> Nikita: But does it really help them? I don't see a lot of differences
> between these two:
if ($type instanceof ReflectionClassType) {
$r = $type->getClass();
}
// and
if (class_exists($type->getName())) {
$r = new ReflectionClass($type->getName());
}
> Levi: ...[I]t will fail for interfaces.] ReflectionClass can be built for
> those but class_exists() will be false.
> Nikita: True :)
The (currently) correct code would be:
if (class_exists($type->getName()) || interface_exists($type->getName())) {
$r = new ReflectionClass($type->getName());
}
But if we add some other type such as enums we may have to add more
conditions. As long as ReflectionClass can be made from the type then
doing it in the engine is fully forward compatible.
I hope people who voted no will share why they have done so, but I
also hope they'll switch to yes if they voted no because they don't
see it as being useful.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
