Re: Add support $object::class

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]