On 1/19/11 10:52 AM, Richard Quadling wrote:

There is a pecl extension called inclued [1]&    [2] which could be used I

It can be used to produce a list of all the relationships between
included files, so a one off pass of all the class files (simply
include them) and then retrieve the analysis from inclued.

You can now build a class dependency tree from that data and cache it.

Pretty much exactly what you need.


While inclued performs a nice analysis of the files included at a given
stage of a script, I don't see that it performs a static analysis of the
contained within the files so Larry could use it to detect the interfaces
implemented in a given set of PHP files.

I looked at the pages:

I'm curious about this feature myself, so if I missed something, please
me know.



Yeah, inclued looks cool but it looks like a runtime analysis tool, not a
static analysis tool.  That runs into the same problem as reflection where
I'd have to include the whole code base in order to build up the indexes I

--Larry Garfield

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

You would only need to do analysis by reflection once per release
though? Just like you would do to build your documentation (using
something like phpdoc for example). You _do_ document your code don't

Yes, the project is very heavily documented, and I can be rather OCD about my Docblocks. :-)

The release cycle for the core system and plugins is not the same, though. Plugins are written on their own schedule and updated whenever. That means we'd need to, at minimum, do a rebuild of an individual plugin at release time and build its manifest, which is still a potentially expensive operation.

Actually, thinking about it, since we cannot guarantee a file location we cannot guarantee a working autoload for reflection until after the index is built that autoload can use. That would rule out any sort of reflection approach that doesn't involve loading every PHP file we can find. Doing that individually for every plugin when it's released could get extremely expensive.

Also, a PECL module is not an option unless it's possible to make a runtime version of it that can be swapped in, since we cannot guarantee the server environment we're running on beyond stock PHP. :-( (Such is life in the open source platform world.)

--Larry Garfield

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to