Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85976
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <553E8258.7040004@gmail.com>
References: <CALW=WEA2pGBuYy0E1V9ywEh_jFUcMksVvJb+GTxYmLCMQXnudQ@mail.gmail.com>
 <CAAyV7nFXn1LT_d0=nYZpxwCz4qWnraGaJeQ18H_k_4bb_oY58A@mail.gmail.com>
 <CADyq6sLPoq5NR6J35aWt-aYznvFf=vhcfNAtPNOk4PKRbNLXOg@mail.gmail.com> <553E8258.7040004@gmail.com>
Date: Mon, 27 Apr 2015 20:53:07 +0100
Message-ID: <CADyq6sKFjzrTM-3k61U3QzxQLHrY+ib022XOqVOXpQL4+pPVUg@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0141a15477dbbe0514ba191d
Subject: Re: [PHP-DEV] Add support $object::class
From: ocramius@gmail.com (Marco Pivetta)

--089e0141a15477dbbe0514ba191d
Content-Type: text/plain; charset=UTF-8

On 27 April 2015 at 19:39, Rowan Collins <rowan.collins@gmail.com> wrote:

> Marco Pivetta wrote on 27/04/2015 18:25:
>
>> On 27 April 2015 at 16:35, Anthony Ferrara <ircmaxell@gmail.com> wrote:
>>
>>  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.
>>>
>>
>> Mainly due to overhead.
>>
>> Having `::class` accessible even for objects and variables containing
>> class
>> names would be very efficient, as it saves us a method call for an
>> operation that really doesn't need one.
>>
>
> The overhead of function calls comes up a lot, and it strikes me that
> optimising calls to built-in functions *as a category* would be better than
> piling more special case syntax into the engine for every use case.
>

Yes, it could be done indeed.

Presumably, $foo::class will never be as fast as Foo::class anyway, because
> the latter can happen *at compile time*, since it needs only follow the
> namespace resolution for class name "Foo" within the current file/block,
> thus having effectively zero overhead once cached.
>

It will never be, but still, following works, and that means that we have
some sort of inconsistency: http://3v4l.org/napVW

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

--089e0141a15477dbbe0514ba191d--