Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103297
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>
In-Reply-To: <CALKiJKqZU2UVWBb_84a6vo_iL7ih7BO1E6sipXyeoUbdYS6_WQ@mail.gmail.com>
Date: Mon, 1 Oct 2018 10:29:58 -0300
Message-ID: <CANA3DesifSNsVmuBjP1XX1s13Qynm3LSki_bn=uC7oZdtPOvOA@mail.gmail.com>
To: rowan.collins@gmail.com
Cc: internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e5b75005772acd43"
Subject: Re: [PHP-DEV] Class name resolution for \array::class
From: marcospassos.com@gmail.com (Marcos Passos)

--000000000000e5b75005772acd43
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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);


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-4=
07600337>
> .


Beside this, deprecating it now would represent a BC break, right?

Em seg, 1 de out de 2018 =C3=A0s 10:15, Rowan Collins <rowan.collins@gmail.=
com>
escreveu:

> On Mon, 1 Oct 2018 at 13:24, Marcos Passos <marcospassos.com@gmail.com>
> wrote:
>
>>
>> You can also see it as a language construct that expects a type at the
>> left-hand side of the name resolution operator. In that sense, primitive
>> types are perfectly valid.
>>
>
>
> While I can see that as an interpretation, it doesn't make a lot of sense=
:
>
> - the keyword "class" implies that this will always return a class name;
> it is the static equivalent of get_class(), which does not support
> non-objects
> - if instead it was resolving a "type", you might expect it to return the
> same values as gettype(), which for any object is simply the string "obje=
ct"
> - the main purpose of the feature is to resolve namespace lookups and
> aliases, but basic types are not subject to namespaces; in other words,
> "int::class" can only ever return "int"
>
> As Marco says, if you have a use case where allowing this is helpful,
> please share it, and we can discuss if this, or some new related feature
> (e.g. "array::type"), would be worth supporting.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>

--000000000000e5b75005772acd43--