>
> - 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'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 às 10:52, Rowan Collins <rowan.coll...@gmail.com>
escreveu:
> On Mon, 1 Oct 2018 at 14:30, Marcos Passos <marcospassos....@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]
>
