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
>> 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
>> if a class implements a given interface by static analysis unless it
>> 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
>> That necessitates that any "detectable" classes must explicitly themselves
>> declare their interfaces, even if it is redundant to do so. I don't like
>> 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
>> 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
>> 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
> Nephtali: A simple, flexible, fast, and security-focused PHP framework
There is a pecl extension called inclued  &  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.
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