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