Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103299
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> <CALKiJKq_-SzCm6wud0YoEU6PskLMGT97iw6w1X5DkJEtZsVZEQ@mail.gmail.com>
In-Reply-To: <CALKiJKq_-SzCm6wud0YoEU6PskLMGT97iw6w1X5DkJEtZsVZEQ@mail.gmail.com>
Date: Mon, 1 Oct 2018 11:04:32 -0300
Message-ID: <CANA3DevbBuuNceieTdUkEMCbsDsjLwjxXet+Yt7QZBy0oEjatQ@mail.gmail.com>
To: rowan.collins@gmail.com
Cc: internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007997a305772b4937"
Subject: Re: [PHP-DEV] Class name resolution for \array::class
From: marcospassos.com@gmail.com (Marcos Passos)

--0000000000007997a305772b4937
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>
> - It doesn't protect against typos like a constant would, because
> \itn::class will reliably and silently resolve to 'itn' whether or not su=
ch
> a class exists.


It's  a good point, I didn't realized that.

Having a ::type pseudo-constant is preferable, indeed. The whole point was
about making it consistent before you stated that this use case become
valid by mistake.

Em seg, 1 de out de 2018 =C3=A0s 10:52, Rowan Collins <rowan.collins@gmail.=
com>
escreveu:

> 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 su=
ch
> 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 work=
s
> by mistake, as demonstrated by array::class not being supported when the
> feature was first added.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>

--0000000000007997a305772b4937--