Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103292
MIME-Version: 1.0
References: <CANA3Dev7BXWrThT8DKn=sSfGnYByUUxh_Yk9yqULeA+9c-uwng@mail.gmail.com>
In-Reply-To: <CANA3Dev7BXWrThT8DKn=sSfGnYByUUxh_Yk9yqULeA+9c-uwng@mail.gmail.com>
Date: Mon, 1 Oct 2018 09:45:01 +0100
Message-ID: <CALKiJKpQ3Sd=Q1OgCGrn+v0oQvHXSSB2GMWvHDdKskvz3gm77g@mail.gmail.com>
To: marcospassos.com@gmail.com
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c86007057726d256"
Subject: Re: [PHP-DEV] Class name resolution for \array::class
From: rowan.collins@gmail.com (Rowan Collins)

--000000000000c86007057726d256
Content-Type: text/plain; charset="UTF-8"

On Mon, 1 Oct 2018 at 00:30, Marcos Passos <marcospassos.com@gmail.com>
wrote:

> Currently, class name resolution supports all types except an array.
> https://3v4l.org/OXFMW
>

It seems to me that the bug is allowing an expression like "int::class" to
resolve, when "int" is no longer a legal class name.

I suspect the reason "array::class" doesn't work is that it was already a
reserved word in PHP 5, whereas other types were legal class names. In PHP
5, "int::class" can plausibly resolve to the name of an actual class, but
in PHP 7, it can't, but clearly this part of the grammar wasn't updated to
reflect that.

The parser is being too forgiving here, I think, and should complain if the
word before :: is not a valid class name.

Regards,
-- 
Rowan Collins
[IMSoP]

--000000000000c86007057726d256--