Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94372
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain telia.com from 81.236.60.155 cause and error)
To: Nikita Popov <nikita.ppv@gmail.com>, Levi Morrison <levim@php.net>
References: <CAFMT4Noe07E9--sasW-Fiw5B1hFFZbXDG2_wumkfZCbqM9wh7A@mail.gmail.com>
 <CAF+90c9RCfLdFGgLVXtc3iPy-LcPK3cfKqHNz-7Mm+QygER1Tg@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
Message-ID: <1f39f97a-6aaf-8550-9f82-a7e80465f903@telia.com>
Date: Mon, 4 Jul 2016 18:51:30 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <CAF+90c9RCfLdFGgLVXtc3iPy-LcPK3cfKqHNz-7Mm+QygER1Tg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC][Vote] ReflectionType Improvements
From: bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)

Den 2016-06-30 kl. 23:57, skrev Nikita Popov:
> 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
>
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