Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85968
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CALW=WEA2pGBuYy0E1V9ywEh_jFUcMksVvJb+GTxYmLCMQXnudQ@mail.gmail.com>
References: <CALW=WEA2pGBuYy0E1V9ywEh_jFUcMksVvJb+GTxYmLCMQXnudQ@mail.gmail.com>
Date: Mon, 27 Apr 2015 11:35:54 -0400
Message-ID: <CAAyV7nFXn1LT_d0=nYZpxwCz4qWnraGaJeQ18H_k_4bb_oY58A@mail.gmail.com>
To: "S.A.N" <ua.san.alex@gmail.com>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Add support $object::class
From: ircmaxell@gmail.com (Anthony Ferrara)

On Mon, Apr 27, 2015 at 7:18 AM, S.A.N <ua.san.alex@gmail.com> wrote:
> Now this code causes an error PHP 5-7.
>
> PHP Parse:
> Syntax error, unexpected 'class' (T_CLASS), expecting identifier
> (T_STRING) or variable (T_VARIABLE) or '{' or '$'
>
> Do not want to use get_class($object)

Why not?

Seriously, why not? ::class was added because there was no easy way to
get from the symbol class name to the string representation of it (you
couldn't pass it to a function, etc since it would look like a
constant). So ::class is a purely compile time construct to turn a
literal classname into a string representation.

However, if you have a variable, there already is a way to do that at
runtime: get_class. What's the problem with that where we need to
further support arbitrary syntax?

Note: I'm not saying we shouldn't add support. I'm just saying that
it's not the same situation as with Bar::class...

Anthony