Re: Class and interface location

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