On 19 January 2011 16:23, la...@garfieldtech.com <la...@garfieldtech.com> wrote: > On 1/19/11 10:09 AM, Adam Richardson wrote: >> >> On Wed, Jan 19, 2011 at 8:21 AM, Richard >> Quadling<rquadl...@gmail.com>wrote: >> >>> On 19 January 2011 07:46, Adam Richardson<simples...@gmail.com> wrote: >>>> >>>> On Wed, Jan 19, 2011 at 2:07 AM, Larry Garfield<la...@garfieldtech.com >>>> wrote: >>>> >>>>> 3) Static analysis. Instead of reflection, either tokenize or string >>> >>> parse >>>>> >>>>> all files to determine what classes implement what interfaces and then >>>>> cache >>>>> that information. We are actually using this method now to locate >>> >>> classes, >>>>> >>>>> and it works surprisingly well. Because we never parse code into >>>>> memory >>> >>> it >>>>> >>>>> does not ever spike the memory usage. However, it is impossible to >>>>> determine >>>>> if a class implements a given interface by static analysis unless it >>>>> declare >>>>> so itself with the implements keyword. If it does so indirectly via >>>>> inheritance, either via the class or via the interface, it would not >>> >>> find >>>>> >>>>> it. >>>>> That necessitates that any "detectable" classes must explicitly >>> >>> themselves >>>>> >>>>> declare their interfaces, even if it is redundant to do so. I don't >>> >>> like >>>>> >>>>> that >>>>> approach, but it's the first one that strikes me as even viable. >>>>> >>>> >>>> 4) Explicit declaration. In this approach we detect nothing and rely on >>> >>> the >>>>> >>>>> plugin developer to do everything. That is, they must provide >>>>> somewhere >>>>> (either in code or a configuration file) an index of all classes they >>>>> offer, >>>>> the interfaces they implement, and the file in which they live. While >>> >>> this >>>>> >>>>> makes the implementation easy, it is a huge burden on the plugin >>> >>> developer >>>>> >>>>> and >>>>> I'm quite sure they'll forget to do so or get it wrong on a regular >>> >>> basis. >>>>> >>>> >>>> I'd suggest combining 3 and 4. Build a tool that performs a static >>> >>> analysis >>>> >>>> of a group of files and make it easy for developers to use. This tool >>> >>> would >>>> >>>> generate the explicit declarations your codebase would utilize when >>>> answering such questions as "which classes implement interface foo". >>>> The >>>> file the static analysis tool generates could be easily hand editable, >>>> so >>>> developers could tweak it if they see issues (just in case the static >>>> analysis tool has bugs early on), or for small plugins, just quick crank >>> >>> out >>>> >>>> a couple lines by hand. >>>> >>>> As long as the static analysis tool builds a composite of class >>>> hierarchy >>>> established in all the files (project wide, at least in terms of the >>>> plugin), you wouldn't have to double declare interfaces so they could be >>>> detected. >>>> >>>> Adam > > That is essentially #3. The static analysis results could easily be cached > in a human-editable form, but in practice I don't think that will be viable. > The humans who will be running this system will largely be non-PHP-gurus so > asking them to validate the accuracy of a giant PHP array dumped to a file > is going to be a losing battle. If we're actually building a full graph to > determine indirect implementation that would then preclude pre-deriving > information per-plugin and just shipping a manifest file with each plugin. > (I could be convinced of that as an approach, but that still doesn't solve > the indirect implementation problem.) > > >>> There is a pecl extension called inclued [1]& [2] which could be used I >>> think. >>> >>> 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. >>> >> >> Richard, >> >> 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 >> PHP >> 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: >> http://docs.php.net/manual/en/inclued.examples-implementation.php >> http://docs.php.net/manual/en/function.inclued-get-data.php >> >> I'm curious about this feature myself, so if I missed something, please >> let >> me know. >> >> Thanks, >> >> Adam > > 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 > need. > > --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 you??? -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
