Re: Re: [VOTE] ::class feature to resolve namespaced class names to scalars

From: Date: Thu, 13 Sep 2012 21:41:57 +0000
Subject: Re: Re: [VOTE] ::class feature to resolve namespaced class names to scalars
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-62991@lists.php.net to get a copy of this message
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

« previous php.internals (#62991) next »