On 1/19/11 11:16 AM, Adam Richardson wrote:
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.
Well, I don't know if it's feasible to do a deep tree at module dev time
individually. To clarify, the code base in question has some 2000+
plugins, of which about 100 may be enabled at any given time on a
particular installation. That means building the manifest for an
individual plugin would require a very extensive build of the entire
development installation for that plugin. A particular class could
implement an interface provided by another plugin, which in turn
inherits from another, which inherits from a core system interface. I'm
just worried that the build process would become very onerous and/or
expensive.
If we kept the "explicit if redundant declaration" requirement, that
makes the rebuild much simpler. I guess that would have to be examined
experimentally.
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.
Eh? I barely comment on this list these days. :-) But thanks.
--Larry Garfield
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
