On 27 April 2015 at 19:39, Rowan Collins <rowan.coll...@gmail.com> wrote:
> Marco Pivetta wrote on 27/04/2015 18:25:
>
>> On 27 April 2015 at 16:35, Anthony Ferrara <ircmax...@gmail.com> wrote:
>>
>> On Mon, Apr 27, 2015 at 7:18 AM, S.A.N <ua.san.a...@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/
