I somewhat agree; using __CLASS__ would make it more obvious that it's
compile-time rather than runtime, IMO.
It's not always going to be compile-time.
For self::class and Foo::class, it will be compile time every time. For
static:class and parent::class, that has to be done at runtime as the
class_entry is not completely hooked up (active_class_entry does not
have parent* pointer, even if the class is extended).
The 99% use case is: Foo::class, where a short name can be resolved
against the current namespace and current import/use statements.
The rest of the use cases, as we've seen, are going to be filled out for
consistency.
That means that:
class Foo {
const SOMECLASSNAME = static::class; // or parent::class
}
Will/should result in an E_FATAL (this use case doesn't really make a
ton of sense anyway, but people are likely to do it).
(I *think* the same applies for method signatures too, btw.)
That is the reason why I voted "no", but more because of the token
used than the feature.
I previously stated that I preferred __CLASS__ as well to be more in
line with what we currently have, I haven't changed my mind since the
arguments provided didn't convinced me at all.
I guess I can't convince preference :)
I prefer ::class over ::__class__, and in that only marginally, because
its shorter. After all, the whole point of this feature is because
people are using namespaces (for the shortness of class names) and they
need to use long class names as string, but want all the benefits of the
namespacing/aliasing in the current scope.
-ralph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
