Re: Class and interface location

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 19 January 2011 07:46, Adam Richardson <simpleshot@xxxxxxxxx> wrote:
> On Wed, Jan 19, 2011 at 2:07 AM, Larry Garfield <larry@xxxxxxxxxxxxxxxx>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
>
> --
> Nephtali: ÂA simple, flexible, fast, and security-focused PHP framework
> http://nephtaliproject.com
>

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.

[1] http://pecl.php.net/package/inclued
[2] http://docs.php.net/manual/en/book.inclued.php

-- 
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




[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux