Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94345
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAFMT4Noe07E9--sasW-Fiw5B1hFFZbXDG2_wumkfZCbqM9wh7A@mail.gmail.com>
References: <CAFMT4Noe07E9--sasW-Fiw5B1hFFZbXDG2_wumkfZCbqM9wh7A@mail.gmail.com>
Date: Thu, 30 Jun 2016 23:57:47 +0200
Message-ID: <CAF+90c9RCfLdFGgLVXtc3iPy-LcPK3cfKqHNz-7Mm+QygER1Tg@mail.gmail.com>
To: Levi Morrison <levim@php.net>
Cc: internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c0356f8ee089e053685f5dd
Subject: Re: [PHP-DEV] [RFC][Vote] ReflectionType Improvements
From: nikita.ppv@gmail.com (Nikita Popov)

--94eb2c0356f8ee089e053685f5dd
Content-Type: text/plain; charset=UTF-8

On Thu, Jun 30, 2016 at 6:06 PM, Levi Morrison <levim@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

--94eb2c0356f8ee089e053685f5dd--