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]
