Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103298
MIME-Version: 1.0
References: <CANA3Dev7BXWrThT8DKn=sSfGnYByUUxh_Yk9yqULeA+9c-uwng@mail.gmail.com>
 <CALKiJKpQ3Sd=Q1OgCGrn+v0oQvHXSSB2GMWvHDdKskvz3gm77g@mail.gmail.com>
 <CANA3DeuGfokS7YgaKTnsQDQO2OASzaTi2OdY8O5mqii-3waDZg@mail.gmail.com>
 <CALKiJKqZU2UVWBb_84a6vo_iL7ih7BO1E6sipXyeoUbdYS6_WQ@mail.gmail.com> <CANA3DesifSNsVmuBjP1XX1s13Qynm3LSki_bn=uC7oZdtPOvOA@mail.gmail.com>
In-Reply-To: <CANA3DesifSNsVmuBjP1XX1s13Qynm3LSki_bn=uC7oZdtPOvOA@mail.gmail.com>
Date: Mon, 1 Oct 2018 14:51:55 +0100
Message-ID: <CALKiJKq_-SzCm6wud0YoEU6PskLMGT97iw6w1X5DkJEtZsVZEQ@mail.gmail.com>
To: marcospassos.com@gmail.com
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000650f4305772b1cfa"
Subject: Re: [PHP-DEV] Class name resolution for \array::class
From: rowan.collins@gmail.com (Rowan Collins)

--000000000000650f4305772b1cfa
Content-Type: text/plain; charset="UTF-8"

On Mon, 1 Oct 2018 at 14:30, Marcos Passos <marcospassos.com@gmail.com>
wrote:

> Sorry, it looks like I've replied to Marco only.
>
> About use case, we use it to specify types in standardized fashion:
>
> if (!$value instanceof Foo) {
>>      throw InvalidArgumentException::unexpectedType($value, Foo::class);
>> }
>> if (!\is_int($value)) {
>>     throw new InvalidArgumentException::unexpectedType($value,
>> \int::class);
>> }
>>
>> $converter->convert($value, \int::class);
>
>

This is just obfuscation for no gain, IMO:

- \int::class is 6 characters longer than 'int', and guaranteed to have the
same value.
- It doesn't protect against typos like a constant would, because
\itn::class will reliably and silently resolve to 'itn' whether or not such
a class exists.
- It implies that "int" is a class, which it is not; and that the methods
always take a class name, which they do not.



> I also said that it might have some benefits for generic types:
>
> I don't disagree with you, but it's already supported right now, so what
>> I'm only proposing to make it consistent.
>> Looking forward, supporting name resolution for primitive may have some
>> benefits for generic types
>> <https://github.com/PHPGenerics/php-generics-rfc/issues/20#issuecomment-407600337>
>> .
>
>

I note that in that discussion, the suggestion of ::type has already come
up, and given its own thread:
https://github.com/PHPGenerics/php-generics-rfc/issues/27

In my view, that would make more sense than officially supporting "::class"
for things other than classes.




> Beside this, deprecating it now would represent a BC break, right?
>


Nit-pick: deprecation is never a BC break; it just implies eventual
removal, which is.

But yes, outright banning it now would be a BC break. IMO it should have
been banned at the same time "int", "string", etc were made illegal class
names (in PHP 7.0), but I can see an argument that our next chance is PHP
8.0.

I still think removing it is the right thing to do, however; it only works
by mistake, as demonstrated by array::class not being supported when the
feature was first added.

Regards,
-- 
Rowan Collins
[IMSoP]

--000000000000650f4305772b1cfa--