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.
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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
