On Wed, Jan 19, 2011 at 11:23 AM, larry@xxxxxxxxxxxxxxxx < larry@xxxxxxxxxxxxxxxx> wrote: > On 1/19/11 10:09 AM, Adam Richardson wrote: > >> On Wed, Jan 19, 2011 at 8:21 AM, Richard Quadling<rquadling@xxxxxxxxx >> >wrote: >> >> 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 >>>> >>> > That is essentially #3. Well, actually the method I was describing (all so poorly) was a hybrid, as I was suggesting that each plugin have a manifest, it's just that you'd build a tool to help them generate it the manifest. > 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. My suggestion to make it human-readable/editable was for the sake of plugin developers, not general users who might install the system. > 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.) Given the current information, I think building a tool that performs the static analysis of interfaces per plugin and then providing that tool to developers so they can build a manifest required per plugin is the best alternative. It minimizes the performance issues by working plugin by plugin, provides flexibility for future information to be included in the manifest if it's ever needed, and could be a user friendly option for developers. Anyways, thanks for sharing your problem, Larry. It's nice to ponder such things. You've shown yourself to be a very capable developer through your comments to the list, and I'm sure whatever approach you take will work well. Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com
