Re: Add support $object::class

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/