Hey Stas,
* Here are the edge cases / implementation details that need a decision:
- $variable::class (should it even be supported?)
I don't see it doing anything useful.
I generally agree.
In the current patch, this does not work and would need another run in
the parser.
- self, static, parent::class not in a class definition
- self, static, parent::class in a method signature
- self, static, parent::class in a method body
In constant context, self:: may work, but static:: can't work for
obvious reasons. parent:: can be made work too I think - though the
class may not be known at the run time, its name should be.
self works in compile-time in the current patch.
static::class and parent::class work in the current patch in run-time,
but they are effectively doing a get_called_class() and
get_parent_class() respectively.
This part of my implementation can be cleaned up to remain in runtime
but utilize zend_do_fetch_class() instead.
As for runtime context, static:: can be made work too but I wonder why
bother if we have perfectly good get_called_class()...
For some people, I think it's a matter of completeness, regardless if it
is a compile-time name resolution or a runtime class lookup.
Personally, (I am not the majority here I feel), I'd rather see
zend_error(E_FATAL) for any runtime lookups, forcing people to use the
runtime-lookup-isms (like get_called_class(), or get_parent_class()).
For the latter, returning "false" there seems more likely, where as
parent::class returning false when not in an inherited class seems odd
to me.
-ralph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
