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)
Thank.
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.
However, if you have a variable, there already is a way to do that at
runtime: get_class. What's the problem with that where we need to
further support arbitrary syntax?
Note: I'm not saying we shouldn't add support. I'm just saying that
it's not the same situation as with Bar::class...
Anthony
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.
Systems that depend on get_class() a lot would benefit from such a
feature: see for example mapping caches in data mappers and handlers
matching in event handlers.
Marco Pivetta
Systems that depend on
get_class()a lot would
An for non-objects types, I suggest that $var::class could return the same
as get_type($var). That would allow saving ref mismatches when $var is a
ref.
2015-04-27 20:33 GMT+03:00 Nicolas Grekas nicolas.grekas@gmail.com:
Systems that depend on
get_class()a lot wouldAn for non-objects types, I suggest that $var::class could return the same
as get_type($var). That would allow saving ref mismatches when $var is a
ref.
+1
Marco Pivetta wrote on 27/04/2015 18:25:
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
::classaccessible 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]
Marco Pivetta wrote on 27/04/2015 18:25:
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
::classaccessible 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
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.However, if you have a variable, there already is a way to do that at
runtime: get_class. What's the problem with that where we need to
further support arbitrary syntax?Note: I'm not saying we shouldn't add support. I'm just saying that
it's not the same situation as with Bar::class...
- get_class($object) - looks bad and long
- Illogically - Bar::class valid syntax, $object::class invalid syntax.
- Function call get_class($object) is slower
Hi!
- get_class($object) - looks bad and long
There's nothing bad in calling functions. Functions are part of PHP and
are completely OK.
- Illogically - Bar::class valid syntax, $object::class invalid
syntax. 3. Function call get_class($object) is slower
Unless you code is doing get_class literally millions of times, and it's
basically all it does, it does not matter. This kind of "optimization"
does not lead to anything but ugly code and waste of time.
--
Stas Malyshev
smalyshev@gmail.com
Why not?
- get_class($object) - looks bad and long
It's a function call. A pretty much self-declarative one at that.
What is "bad" about it? For that matter, what's "long" about it? It's
pretty short as PHP function calls go.
- Illogically - Bar::class valid syntax, $object::class invalid syntax.
I'll grant you the consistency argument. I'm all for consistency, but
that's the ONLY valid reason you've stated.
- Function call get_class($object) is slower
Not so much so that you'd notice. Fix the performance issues which
actually make an impact first. When you've done that, THEN come back.
(Hint: You haven't)
-Sara
- Illogically - Bar::class valid syntax, $object::class invalid syntax.
I'll grant you the consistency argument. I'm all for consistency, but
that's the ONLY valid reason you've stated.
Even then I think this part of the argument is fairly weak. In
Bar::class, the context of Bar is always a class name (either short due
to do namespace or use statements, or long fully qualified).
$object is not guaranteed to be an object, it could be anything (int,
string, etc) or nothing (null). using ::class for a variable, I'd
argue, makes for less consistency. What would the replacement be for
non-object variables? An error, exception, or false, or string type?
At least in "Bar::class", you'll always get a string representation of
what the fully qualified class name resolves to.
That said, the argument could be made that since static::class,
self::class, and parent::class fall into the same category of potential
runtime resolutions that $object::class too should be supported.
-ralph
- Illogically - Bar::class valid syntax, $object::class invalid syntax.
I'll grant you the consistency argument. I'm all for consistency, but
that's the ONLY valid reason you've stated.Even then I think this part of the argument is fairly weak. In
Bar::class, the context of Bar is always a class name (either short due to
do namespace or use statements, or long fully qualified).$object is not guaranteed to be an object, it could be anything (int,
string, etc) or nothing (null). using ::class for a variable, I'd argue,
makes for less consistency. What would the replacement be for non-object
variables? An error, exception, or false, or string type? At least in
"Bar::class", you'll always get a string representation of what the fully
qualified class name resolves to.
Hey Ralph,
Please refer to current behavior:
Marco Pivetta
$object is not guaranteed to be an object, it could be anything (int,
string, etc) or nothing (null). using ::class for a variable, I'd argue,
makes for less consistency. What would the replacement be for non-object
variables? An error, exception, or false, or string type? At least in
"Bar::class", you'll always get a string representation of what the fully
qualified class name resolves to.
$scalar::class === gettype($scalar)
$object::class === get_class($object)
That said, the argument could be made that since static::class, self::class,
and parent::class fall into the same category of potential runtime
resolutions that $object::class too should be supported.
+1