> > - 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] >