Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85975
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.52 as permitted sender)
Message-ID: <553E8258.7040004@gmail.com>
Date: Mon, 27 Apr 2015 19:39:20 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CALW=WEA2pGBuYy0E1V9ywEh_jFUcMksVvJb+GTxYmLCMQXnudQ@mail.gmail.com> <CAAyV7nFXn1LT_d0=nYZpxwCz4qWnraGaJeQ18H_k_4bb_oY58A@mail.gmail.com> <CADyq6sLPoq5NR6J35aWt-aYznvFf=vhcfNAtPNOk4PKRbNLXOg@mail.gmail.com>
In-Reply-To: <CADyq6sLPoq5NR6J35aWt-aYznvFf=vhcfNAtPNOk4PKRbNLXOg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Add support $object::class
From: rowan.collins@gmail.com (Rowan Collins)

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.

Is this a fundamentally hard problem? Could there be some way of writing 
certain internal functions such that they're accessible as normal calls 
(for use with call_user_func etc) but also optimisable to something more 
similar to an opcode call (which seems to be the alternative) by the 
OpCache?

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.

Regards,
-- 
Rowan Collins
[IMSoP]