>From my point of view, the concept of a "file" has become semantically more
important, and increasingly relevant to Reflection, with the latest PHP
features added in the past couple of years.
I can see what you mean though - it's probably not a small effort, and
there are probably more important aspects of PHP that need attention...
2012/1/29 Johannes Schlüter <johan...@schlueters.de>
> Hi,
>
>
> On Sun, 2012-01-29 at 18:51 -0500, Rasmus Schultz wrote:
> > I realized the other day that ReflectionFile is missing from the
> Reflection
> > API.
>
> As is ReflectionNamespace and some others one might think about. In the
> end it boils down to the fact that we don't have structures internally
> representing them as for PHP there is no need to keep the data and then
> we're restrictive in adding such meta-data just for the purpose of
> reflection. Mind that we'd have to keep all that in memory and opcode
> caches have to copy it around etc. in the end the consensus was: the
> effort needed doesn't seem worthwhile.
>
> The alternative would be to "emulate" it, something like
>
> class ReflectionFile {
> private $filename;
> private $classes = array();
> private $functions = array();
>
> private initFunctions($filename) {
> foreach(get_defined_functions()['user'] as $f) {
> $rf = new ReflectionFunction($f);
> if ($rf->getFilename() == $filename) {
> $this->functions[$rf->getName()] = $rf;
> }
> }
> }
>
> private initClasses($filename) { /* ... */ }
>
> public __construct($filename) {
> $this->filename = realpath($filename);
> $this->initFunctions($this->filename);
> /* ... */
> }
>
> public getFunctions() {
> return $this->functions;
> }
>
> public getFunctionNames() {
> return array_keys($this->functions);
> }
>
> /* ... */
> }
>
> But that feels more like a hack than a solution, too.
>
> johannes
>
> PS. Mind that the example you've given even works on files not included
> by parsing files, whereas internal reflection provides information what
> actually is available from engine point of view ...
>
>
