[wp-hackers] Plugin dependency checking

Mike Schinkel mikeschinkel at newclarity.net
Wed Jun 17 19:29:02 GMT 2009


On Jun 17, 2009, at 3:12 PM, scribu wrote:
>
> About option nr. 3, I don't see the real benefit of explicitly
> defining the interface.

Including, but not limited to:

-- Ability to validate during development that a plugin that  
implements an interface has done so correctly  
-- Ability to extract documentation for a plugin author (WordPress  
itself could define its interfaces) 
-- Ability for a developer to know explicitly what the other developer  
meant when he defined the interface
-- Ability to do explicit rather than implicit coupling [1]
-- Ability to do code coverage testing [2]
-- Ability to do (semi-)automated unit testing [3]
-- Ability for plugin developers to see, at-a-glance in a well-defined  
way, what the touch-points are for a plugin.

For example I'm currently using Thesis theme and it has 50+ hooks,  
numerous global variables, several options, etc.  If it defined those  
as interfaces I could easily see all that, and the documentation would  
be maintained during development, not created after.

Also, much (but not all) of the interface could be auto-generated via  
a tool the developer could use.

And I'm thinking the ability to do semi-automated unit testing should  
alone make for a reason to do this.

> I can already envision me defining an explicit interface, then I
> update the plugin and subsequently forget to update the interface.

That would only happen if you tested the site in deployment vs.  
development mode. If you tested in development mode it would tell you  
that you have a problem.

> Also, we shouldn't put our hopes up for interfaces.wordpress.org.


Agreed, but first things first.  We can do proof of concept at  
interfaces.yourormysite.com and then the benefits are likely to be  
obvious enough to get agreement.

-Mike Schinkel
WordPress Custom Plugins
http://mikeschinkel.com/custom-wordpress-plugins/

[1] http://en.wikipedia.org/wiki/Coupling_(computer_science)
[2] http://en.wikipedia.org/wiki/Code_coverage
[3] http://en.wikipedia.org/wiki/Unit_testing

On Jun 17, 2009, at 3:12 PM, scribu wrote:

> On 6/17/09, Mike Schinkel <mikeschinkel at newclarity.net> wrote:
>>> For now, I'd just like to say that having to call a remote registry
>>> for each plugin, on each page load, by default, is a *very* bad  
>>> idea.
>>
>> Agreed. But I was not proposing that. I was only proposing a call  
>> to a
>> registry once upon plugin activation.
>>
>> One call to a web service with a list of of plugins on activation  
>> that
>> returns a list of registered interfaces is certainly not a legitimate
>> performance concern for clients or for the server, right?
>
> Sorry, didn't catch the part about "once upon plugin activation".
>
> About option nr. 3, I don't see the real benefit of explicitly
> defining the interface.
>
> I can already envision me defining an explicit interface, then I
> update the plugin and subsequently forget to update the interface.
>
> Also, we shouldn't put our hopes up for interfaces.wordpress.org.
>
>
> --
> http://scribu.net
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers



More information about the wp-hackers mailing list