Plugin dependency checking

[Burt Adsit-3]

Haha. (Sorry). I've been trying to keep up with this thread and have
been doing fairly well up to this point. Austin, could you put this last
bit a little less concisely?

Austin Matzko wrote:
> If it's a matter of wanting the child plugins to be able to redefine
> the pluggable function, you could let the parent plugin define the
> pluggable function as a wrapper of a parent plugin's factory method,
> which would then open up the possibility of child plugins re-defining
> the behavior of the pluggable function.
>  

--
Code Is Freedom
Burt Adsit

_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Austin Matzko]

On Fri, Jun 12, 2009 at 7:29 PM, Burt Adsit<burt@...> wrote:

> Austin Matzko wrote:
>>
>> If it's a matter of wanting the child plugins to be able to redefine
>> the pluggable function, you could let the parent plugin define the
>> pluggable function as a wrapper of a parent plugin's factory method,
>> which would then open up the possibility of child plugins re-defining
>> the behavior of the pluggable function.
>
> Haha. (Sorry). I've been trying to keep up with this thread and have been
> doing fairly well up to this point. Austin, could you put this last bit a
> little less concisely?

Let's say you want either a parent plugin or one of its children to be
able to redefine the behavior of a pluggable function, such as
wp_authenticate().

Then in the parent plugin, you could have something like the following:

class ParentPluggableAuthenticate {
   function __construct($username, $password)
   {
      // some logic to determine which child plugin's method should be
used to replace wp_authenticate()'s functionality
      // call that child method
   }
}

function wp_authenticate($username, $password) {
   return new ParentPluggableAuthenticate($username, $password);
}

Or something like that.
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Stephen Rider]

LOL.  I followed it, but it *is* starting to sound a bit like an  
Abbott and Costello routine...
;-)

Stephen

On Jun 12, 2009, at 7:29 PM, Burt Adsit wrote:

> Haha. (Sorry). I've been trying to keep up with this thread and have  
> been doing fairly well up to this point. Austin, could you put this  
> last bit a little less concisely?
>
> Austin Matzko wrote:
>> If it's a matter of wanting the child plugins to be able to redefine
>> the pluggable function, you could let the parent plugin define the
>> pluggable function as a wrapper of a parent plugin's factory method,
>> which would then open up the possibility of child plugins re-defining
>> the behavior of the pluggable function.

_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Stephen Rider]

On Jun 12, 2009, at 11:34 AM, Mike Schinkel wrote:

>> The same plugin appearing in more than one place will
>> confuse the heck out of users.
>
> While I like your sub-plugin model, will it confuse users if two (2)  
> different plugins use the same sub-plugin?  I know you are thinking  
> of plugins specifically made for another plugin but someone could  
> easily choose to implement the same interface so they could have  
> ready-made add-ins for their own plugin.

Could you give me an example, because seriously I can't think of any.  
Again note the distinction between dependent plugins and sub-plugins.

If I make a "Spam Karma ReCaptcha" sub-plugin with "Spam Karma" as the  
master, I can't imagine that ever being *also* a sub plugin for some  
other plugin.

If you're talking a framework plugin, you have it turned around.  The  
Framework would be the master, and plugins based on it would be  
dependent on it (but probably NOT sub-plugins.)

Stephen

_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Mike Schinkel-5]

"Stephen Rider" <wp-hackers@...> wrote:

>>> The same plugin appearing in more than one place will
>>> confuse the heck out of users.
>>
>> While I like your sub-plugin model, will it confuse users if two (2)  
>> different plugins use the same sub-plugin?  I know you are thinking  
>> of plugins specifically made for another plugin but someone could  
>> easily choose to implement the same interface so they could have  
>> ready-made add-ins for their own plugin.
>
> Could you give me an example, because seriously I can't think of any.  
> Again note the distinction between dependent plugins and sub-plugins.

Sure I can give an example and one I think is highly likely.

Let's say the fine folks who are offering WP e-Commerce decided to create payment processor sub-plugins; one for PayPal, one for Google Checkout, etc. etc.  I in my opportunistic wisdom decide to create my own ecommerce solution targeted at video cartoon characters with blogs on WordPress which I choose to call "WP Super Mario Cart" (oblivious to the obvious trademark lawsuits that will be hurled at me.) But rather than worry about implementing all those tedious payment processing modules I just implement the same interface that WP e-Commerce chose to implement. Presto bango, I now have a bunch of dependent sub-plugins that will work for my new shopping cart.

> If I make a "Spam Karma ReCaptcha" sub-plugin with "Spam Karma"
> as the master, I can't imagine that ever being *also* a sub plugin
> for some other plugin.

All tongue-in-cheek aside I do very much see wanting to share payment processor plugins, probably more likely than two plugins using the same anti-spam plugin (but you never know.) One pearl I learned from someone much wiser than me was that while finding a needle in a haystack may be hard, it's practically impossible to prove that a needle does not exist in that haystack (i.e. you can't prove a negative.)  Even though, I can imagine that another plugin might want to use your Recaptcha sub-plugin. After all, that's one of the things that makes open-source so vibrant and valuable; i.e. the ability to directly reuse what someone else has previously made available for use in a different context.

Backing into someone else's successful extension model is a savvy business move, look how many years it worked for Compaq on the hardware side. So I guess what I'm saying is I don't see the difference between multi-dependent plugins and single dependent sub-plugins except for the fact that at the moment the latter has one on plugin for which it depends whereas the former currently has many.

But I don't think this is a deal killer for the admin UI, just something to consider.  Maybe the approach is to list those sub-plugins underneath both of the plugins on which they are applicable.

However as I write this is occurs to me that your concept of "dependent plugins" and "sub-plugins" is really just the concept of "interfaces" like from Java, .NET, and PHP5.

   http://java.sun.com/docs/books/tutorial/java/concepts/interface.html
   http://php.net/manual/en/language.oop5.interfaces.php

Your sub-plugins "implement" an interface albeit a defacto one and one that is higher level than built into Java or PHP5 (Java & PHP5 know nothing of WordPress "hooks", for example.) Any plugin that depends on another plugin probably a defacto interface. Note that the interface can be "out-of-band", for example the sub-plugin could share options with the master plugin and never actually call any of it's functions, though that's not all that likely I don't think.

This interface concept is extremely powerful. From Sun's page:

"For example, imagine a futuristic society where computer-controlled robotic cars transport passengers through city streets without a human operator. Automobile manufacturers write software (Java, of course) that operates the automobile—stop, start, accelerate, turn left, and so forth. Another industrial group, electronic guidance instrument manufacturers, make computer systems that receive GPS (Global Positioning System) position data and wireless transmission of traffic conditions and use that information to drive the car.

The auto manufacturers must publish an industry-standard interface that spells out in detail what methods can be invoked to make the car move (any car, from any manufacturer). The guidance manufacturers can then write software that invokes the methods described in the interface to command the car. Neither industrial group needs to know how the other group's software is implemented. In fact, each group considers its software highly proprietary and reserves the right to modify it at any time, as long as it continues to adhere to the published interface."

So having the idea of what I call a "Well-known Interface" is really useful even if it's not a formal interface. A well-known interface encourages reuse and solution growth. WordPress core's "hook" system is really a well-known interface, so is the Thesis theme's set of hooks.

If you already knew all this about interfaces, forgive me. Some people on wp-hackers have a deep computer science background and others first learned to program in order to modify WordPress and since I don't know who knows what I figured I'd inject a bit of this background.

I'm now thinking it would be really useful if we were to create an WP_Interface() class to formally recognize this concept as an OPTION for those who are implementing plugins that use dependent & sub-plugins. A WP_Interface() would define everything about how a plugin would and should be used by a dependent & sub-plugin even if some of that definition were simply prose. It would be part documentation, part validation and possibly part implementation.  

For example, upon plugin activation WordPress could validate sub-plugins against their defined WP_Interface if such an interface exists.  Hell, WordPress could validate all plugins against a WP_Interface("WordPress","2.9") if we agree to define it:

One of the big benefits of such an interface would be documentation (WOW!):

   $wpi = New WP_Interface("WordPress","2.9");
   $wpi->print();

The other benefit would be validation:

   $wpi = New WP_Interface("Spam Karma","1.0");
   if (!$wpi->validate("spam-karma-recaptcha"))
      echo "Sorry: this version of Spam Karma Recaptcha is not compatible with this version of Spam Karma.";

Validation would be HUGELY beneficial. If could allow us to disable non-conforming plugins during an upgrade and even make it possible to determine if there will be problems prior to an upgrade. WP_Interface() would go a long way towards making larger companies and agencies more comfortable with using WordPress because over time it would increase the robustness of the WordPress platform.

Again, I stress that what I'm proposing would be OPTIONAL in all cases, but opting for it would make it easier for people who want to implement an interface and it would make it so we could validate plugins against that interface. It would also typically only be used during activation and not on each page load so it wouldn't impact site performance except marginally upon activation. I'd be happy to work on this if others see it has value.  I'd want to collaborate on it with a least a few others, possible via a Google group (so as not to flood this list with discussions.)

Wrapping up by coming back to your concept of "dependent plugins" vs. "sub-plugins" I really don't think we should make any such distinction. I think t he only difference should be the fact one has code that uses the other or OPTIONALLY they define the relationship using a potential WP_Interface().  As for the admin UI I do agree that it would be nice to have a way to display those that are generally only there to be supportive of another plugin in a tree view up that plugin, but that should be determined by WordPress inspecting the two plugins not by anything defining a plugin as a "master" and another as a "slave." IMO, anyway.

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

P.S. I think I now need to go back and re-read the entire thread because I hadn't paid close enough attention to see how (in)compatible it is with the WP_Interface() concept.
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[scribu]

>
> Ok, thanks for the pointers. I'll see if I can manage to pull off the
> activation hook workaround without modifying the active_plugins list.
>

So I've managed to call a function from the parent plugin when the child
plugin is activated (yes, I actually need that), without interfering with
the loading order:

Parent plugin: http://wp.pastebin.ca/1458835
Child plugin: http://wp.pastebin.ca/1458837

I just wrote it to see if it can be done.

--
http://scribu.net
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Mike Schinkel-5]

scribu:

Looking at your code it appears you are assuming a parent-child inheritance relationship?  Did I follow it correctly?

I hadn't considered dependent plugins having a parent-child inheritance relationship but I guess there are use-cases where that would make sense though I can't immediately think of one.

Still, does your approach *require* a parent-child inheritance relationship?  For my envisioned use-cases with one example being the payment processors plugins for an shopping cart plugin I see a lot more "uses a" relationships than "is a" relationships between a plugin and it's dependents.

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

----- Original Message -----
From: "scribu" <scribu@...>
To: wp-hackers@...
Sent: Saturday, June 13, 2009 7:31:28 AM GMT -05:00 US/Canada Eastern
Subject: Re: [wp-hackers] Plugin dependency checking

>
> Ok, thanks for the pointers. I'll see if I can manage to pull off the
> activation hook workaround without modifying the active_plugins list.
>

So I've managed to call a function from the parent plugin when the child
plugin is activated (yes, I actually need that), without interfering with
the loading order:

Parent plugin: http://wp.pastebin.ca/1458835
Child plugin: http://wp.pastebin.ca/1458837

I just wrote it to see if it can be done.

--
http://scribu.net
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[scribu]

>
> Still, does your approach *require* a parent-child inheritance
> relationship?
>

No, child_class does not *extend* parent_class or parent_tool, if that's
what you were asking.

But for the activation thing to work, the child class has to call
parent_plugin_activation().

--
http://scribu.net
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Stephen Rider]

NOTE:

You can read all of this for the discussion, or you may just choose to  
jump to the bottom, where the rug gets yanked out from under....


On Jun 13, 2009, at 1:56 AM, Mike Schinkel wrote:

> "Stephen Rider" <wp-hackers@...> wrote:
>>> While I like your sub-plugin model, will it confuse users if two (2)
>>> different plugins use the same sub-plugin?  I know you are thinking
>>> of plugins specifically made for another plugin but someone could
>>> easily choose to implement the same interface so they could have
>>> ready-made add-ins for their own plugin.
>>
>> Could you give me an example, because seriously I can't think of any.
>> Again note the distinction between dependent plugins and sub-plugins.
>
> Sure I can give an example and one I think is highly likely.
>
> Let's say the fine folks who are offering WP e-Commerce decided to  
> create payment processor sub-plugins; one for PayPal, one for Google  
> Checkout, etc. etc.  I in my opportunistic wisdom decide to create  
> my own ecommerce solution targeted at video cartoon characters with  
> blogs on WordPress which I choose to call "WP Super Mario  
> Cart" (oblivious to the obvious trademark lawsuits that will be  
> hurled at me.) But rather than worry about implementing all those  
> tedious payment processing modules I just implement the same  
> interface that WP e-Commerce chose to implement. Presto bango, I now  
> have a bunch of dependent sub-plugins that will work for my new  
> shopping cart.

So... we have "WP e-Commerce" and "Paypal Module" sub-plugin for WP e-
Commerce.  Paypal Module plugin has some code in it that says "this is  
a sub-plugin of WP e-Commerce".  *By Definition* that means it is  
dependent on WP e-Commerce.  (Sub plugins are just a special kind of  
dependent plugin.)  That means that unless WP e-Commerce is present  
and activated, Paypal Module *doesn't even load*.  You would have to  
hack it to say "This is a sub-plugin of Mario Cart".

This is all very similar to frameworks.  Something I've been working  
on, on the side, is a WP plugin framework called Strider Core.  When I  
get it done, all of my plugins are going to be built on top of it.  In  
this situation I would not use the sub-plugin formula but simple  
dependencies -- Strider Core would be a plain-old plugin and the  
others would have the Header that says "this plugin depends on Strider  
Core".

Here's another thought.  If someone deletes a plugin that has subs,  
all of its sub-plugins should logically be deleted along with it,  
because *by definition* the sub plugins are nothing without their  
Master plugin.  IF I get rid of "Spam Karma", I really don't need the  
"Spam Karma Anubis" plugin sticking around.  In fact I don't need any  
of the TEN sub-plugins that ship with Spam Karma.

What you're asking for in your example is the ability to switch from  
Push to Pull -- you want a plugin to be able to say, "Plugin Z is a  
sub-plugin of Me".

The **simplest** solution to your example is that PayPal module  
shouldn't have ANY dependencies.  It's just some functions and an  
add_action, which doesn't do anything unless some other plugin calls  
the corresponding do_action.  You're not asking for real dependency,  
you just want the visual appearance of a sub-plugin.

Might be doable, but it's a different thing.  Here's the real UI  
problem with that though:

Okay, Paypal Module appears on the Plugins list underneath both WP e-
Commerce and Mario Cart.  I go to the one under WP e-Commerce and  
deactivate it.  Ooops!  I just deactivated it for Mario Cart too!  In  
WordPress, a plugin is either activated or it's not (at runtime the  
file is either include()ed or it isn't.)  What you need is code within  
the two Cart plugins that say "use sub-plugin X or don't", which is --  
and should be -- beyond the scope of WP's plugin management.


<snip>
> If you already knew all this about interfaces, forgive me. Some  
> people on wp-hackers have a deep computer science background and  
> others first learned to program in order to modify WordPress and  
> since I don't know who knows what I figured I'd inject a bit of this  
> background.

Heh.  I learned programming by typing games into my Apple ][+.  Still,  
more of the latter than the former.  :)

> Validation would be HUGELY beneficial. If could allow us to disable  
> non-conforming plugins during an upgrade and even make it possible  
> to determine if there will be problems prior to an upgrade.  
> WP_Interface() would go a long way towards making larger companies  
> and agencies more comfortable with using WordPress because over time  
> it would increase the robustness of the WordPress platform.

Are you talking about what Firefox does where add-on authors have to  
continually update their add-ons just to bump the version of Firefox  
that their stuff is compatible with?

> Wrapping up by coming back to your concept of "dependent plugins"  
> vs. "sub-plugins" I really don't think we should make any such  
> distinction.

They are basically the same thing.

Dependent means that if Henchman Plugin is dependent on Boss  
Plugin(s), Henchman doesn't even load (in PHP, isn't included) unless  
Boss is loaded.

A Sub-Plugin is exactly the same, except for the added UI that it  
appears underneath a specified Boss in Manage Plugins, and if that  
specific Boss is deleted, so are all Subs.

> As for the admin UI I do agree that it would be nice to have a way  
> to display those that are generally only there to be supportive of  
> another plugin in a tree view up that plugin, but that should be  
> determined by WordPress inspecting the two plugins not by anything  
> defining a plugin as a "master" and another as a "slave." IMO, anyway.


...

*sigh*  10,000 words later, I think you've talked me out of the whole  
idea.  I'm seeing problems with the whole plan.

Plugins can already make themselves dependent on another by checking  
for the existence of the needed functions from the "master".  Or they  
can just offer up functionality via add_action that is called or not  
by some other plugin.

The only REAL important part of all this is that the dependency  
relationship allows for proper loading order.

So... rather than Master/Slave, or even "dependent", what we need is  
something in WP Core that allows for some plugins to say "offers X"  
and others to say "uses X"; and if the two match up then we get the  
"sub plugin" UI changes.  (And forget the bit about deleting sub-
plugins!)  This is really a complete change from previous discussion,  
but probably the best.

Stephen

--
Stephen Rider
http://striderweb.com/




_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Mike Schinkel-5]

scribu:

I'm trying to understand this.  I think I'm struggling with the Parent/Child metaphor where the child can't exist w/o the (specific) parent much like how an (child) Line Item cannot exist without the context of a (parent) Invoice.

I'm thinking plugins are more like functions that can be called by other functions, or like URLs that can be linked from pages located at other URLs.  In both of those cases that called/linked function/URL doesn't have to define it's caller/referrer.

So are you suggesting a model that requires all child plugins identify their parents?  IOW, a model were no child plugins could be used by more than one parent plugin?

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

----- Original Message -----
From: "scribu" <scribu@...>
To: wp-hackers@...
Sent: Saturday, June 13, 2009 9:14:04 AM GMT -05:00 US/Canada Eastern
Subject: Re: [wp-hackers] Plugin dependency checking

>
> Still, does your approach *require* a parent-child inheritance
> relationship?
>

No, child_class does not *extend* parent_class or parent_tool, if that's
what you were asking.

But for the activation thing to work, the child class has to call
parent_plugin_activation().

--
http://scribu.net
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Mike Schinkel-5]

"Stephen Rider" <wp-hackers@...> wrote:
> So... rather than Master/Slave, or even "dependent", what
> we need is something in WP Core that allows for some plugins
> to say "offers X" and others to say "uses X"; and if the two
> match up then we get the "sub plugin" UI changes.  

Dayum! I should have read ahead. I just wrote a ton and in this last paragraph you essentially described interfaces.  So I deleted everything that came before and am just sending this. If the WP community would instead want to call it "offers" instead of "interfaces" then that's completely copasetic with me.

I think we'd probably want something like this:

// Parent Plugin
wp_defines('my_offering.php');
wp_uses('my-offering',1.0);
...

// Child Plugin
wp_defines('my_offering.php');
wp_offers('my-offering',1.5);
...

// In WP Core
function wp_defines($file) {
  if ($GLOBALS['validate_offerings'])
    require_once($file);
}
function wp_uses($name,$version) {
  if ($GLOBALS['validate_offerings'])
    ...
}
function wp_offers($name,$version) {
  if ($GLOBALS['validate_offerings'])
    ...
}

// In my_offering.php
$o = new WP_Offering('my-offering');
$o->add_hook('foo','This hooks does foo.');
$o->add_hook('bar','This hooks does bar.');
$o->add_other_stuff('other stuff','This does other stuff.');
add_offering($o);

Now I haven't tried to implement any of this so the stuff in "my_offering.php" might need to be vastly different and of course maybe the "offering" part is too paganistic for this day and age, but you get the idea. :-)

-Mike Schinkel
Custom Wordpress Plugins
http://mikeschinkel.com/custom-wordpress-plugins
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[scribu]

On Mon, Jun 15, 2009 at 7:28 AM, Mike Schinkel
<mikeschinkel@...>wrote:

> I'm thinking plugins are more like functions that can be called by other
> functions, or like URLs that can be linked from pages located at other URLs.
>  In both of those cases that called/linked function/URL doesn't have to
> define it's caller/referrer.


Just as with regular plugins, you have to call add_action() and
add_filter(), the same happens with child-parent plugins. They can't be
completely separated.

So are you suggesting a model that requires all child plugins identify their
> parents?  IOW, a model were no child plugins could be used by more than one
> parent plugin?
>

One or more child plugins can use functionality provided by one parent
plugin. Parent plugins are not aware of the additional functionality that
each child plugin provides. That's the basic model.

In my activation hook example, the parent plugin simply fires one of it's
own functions with the parameters provided by the child plugin. (I could
have created a second child plugin that called the same parent plugin, but
with different params.)

--
http://scribu.net
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Mike Schinkel-5]

"scribu" <scribu@...> wrote:
> One or more child plugins can use functionality provided by one
> parent plugin. Parent plugins are not aware of the additional
> functionality that each child plugin provides. That's the basic
> model.

As with discussion with Steven on the list, let me urge not to have the child name its parent but instead have the child name the "interface" that its parents can consume.  Steven called is "offers" and "uses"; most any terms will work but coupling children directly to parents will really limit what can be done with their children and IMO would be a mistake.

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

_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[scribu]

Ok, now I get what you were trying to say with "Interfaces".

Yes, not using interfaces would would limit what could be done with
their children, but on the other hand, interfaces would limit what
child plugins could do themselves. It's a tradeoff.

It's the same tradeoff that would happen if normal plugins would have
to have an interface that the core would have to check.

On 6/16/09, Mike Schinkel <mikeschinkel@...> wrote:

> "scribu" <scribu@...> wrote:
>> One or more child plugins can use functionality provided by one
>> parent plugin. Parent plugins are not aware of the additional
>> functionality that each child plugin provides. That's the basic
>> model.
>
> As with discussion with Steven on the list, let me urge not to have the
> child name its parent but instead have the child name the "interface" that
> its parents can consume.  Steven called is "offers" and "uses"; most any
> terms will work but coupling children directly to parents will really limit
> what can be done with their children and IMO would be a mistake.
>
> -Mike Schinkel
> Custom Wordpress Plugins
> http://mikeschinkel.com/custom-wordpress-plugins
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers@...
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>

--
http://scribu.net
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Mike Schinkel-5]

"scribu" <scribu@...> wrote:
> Yes, not using interfaces would would limit what could be done
> with their children, but on the other hand, interfaces would
> limit what child plugins could do themselves.

How so?  I don't see it.

Minimally (for the proposed use in WordPress) an "interface" is simply a name that parent and child agree to offer and to use.  It could be more than just a name but it would not have to be.

> It's the same tradeoff that would happen if normal plugins would
> have to have an interface that the core would have to check.

I think it would be the other way around, i.e. core would implement (an) interface(s) that plugins would use. BTW, that is what already happens implicitly anyway, so we are not loosing anything by formalizing into a name.

Let me see if I can find time to work on some examples. I think you'll "see" it more readily with code.

-Mike Schinkel
Custom Wordpress Plugins
http://mikeschinkel.com/custom-wordpress-plugins
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Shane A. Froebel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I got some good news. While I was reading all these messages I went
ahead (and watching ID4) I created a new "class":

WP_Dependency

This class with the proper registration of the plugin when it's read
will test to see if the theme or plugin will allow you to even activate
once it's tied into the WordPress main code.

I just finished the "class" and didn't tie it into any WordPress code
code. Just a test file.

The way I have it "coded" right now is that when the plugin is even
placed in WordPress it attaches itself to the 'register' part of the
class so it can say 'Hello. I am installed and these are my dependencies
based on version of WordPress and Plugins Needed and their versions for
me to work properly.'

I am working on one more feature that was suggested on the
#wordpress-dev channel. There be a field for 'recommended' for the
plugin dependencies. A little warning would show up only saying that you
should have at least this version, but not required. Let me know what
you think about this.

I'll post the sample code on my website (bugssite.org) in later in the day.

Your Friend,
Shane

Mike Schinkel wrote:

> "scribu" <scribu@...> wrote:
>> Yes, not using interfaces would would limit what could be done
>> with their children, but on the other hand, interfaces would
>> limit what child plugins could do themselves.
>
> How so?  I don't see it.
>
> Minimally (for the proposed use in WordPress) an "interface" is simply a name that parent and child agree to offer and to use.  It could be more than just a name but it would not have to be.
>
>> It's the same tradeoff that would happen if normal plugins would
>> have to have an interface that the core would have to check.
>
> I think it would be the other way around, i.e. core would implement (an) interface(s) that plugins would use. BTW, that is what already happens implicitly anyway, so we are not loosing anything by formalizing into a name.
>
> Let me see if I can find time to work on some examples. I think you'll "see" it more readily with code.
>
> -Mike Schinkel
> Custom Wordpress Plugins
> http://mikeschinkel.com/custom-wordpress-plugins
> _______________________________________________
> wp-hackers mailing list
> wp-hackers@...
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJKN2HiAAoJEChMcQvNqPqmDb8P/3mAOTqkP+ooaoQE28qbryXe
PhYXz7c5MMm4qN8XHT6rZ+vk1WkBTvs+N4snNMRcS4Qo2jIodnd7+7+drAfPi1vb
LYvvc0d+w4Bet6wL0xuXauBPJkvK3KvqFL0EWDOEdzBVnCpC//zwXm/XMxxzB7pC
gjzHiVI0h3Hcf6k7pLcOiM4RBCzjmx0aaD23gWHd6gWU7VTZ6KOKb5TfwkgZ6b4C
YCgf83oRqj5t16hCVu35rjjYdcr6NRJDq9udZAWNAJkKrRFMO8L+RVO0M/ofFJTa
o04bE0YrXlsg72cw6kgfWcirCOXNxTo+9pRQ4m3vXO7LkTbrTfkQvft7pWU1qh3D
oLY4Y7+nBDOBLRybRU6mCtPf9A9gzb0Csv+AFOQq1dLeWFEjMXKyhbTj13v0xmf5
pMFomLb59I/o3w4MP+dfV+RI4XW66ufjqwhIbJ4zKOnHbR3msIiAGxdsK7O0scXK
oE83QfcoDneET+iC6vf8XhETYnjwggDIxy/gswKLy9iPlTP6OUtb19ShHlVPUtes
r+Tu6aI4mYGajzk2GMG0X874f2O3d/WyFNc4Nsvab4hLq6wm7IPoDgnmmV3sWWqi
gfusmzHIQPH/pBtCEH0B1U+dMHktiy+vOEhQQLyw/tgfbkTQVP9IEr5JDgNT72Wo
VsIW8Nx28BTQDqmTuqZm
=82Yt
-----END PGP SIGNATURE-----
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Stephen Rider]

On Jun 15, 2009, at 6:39 PM, Mike Schinkel wrote:

> As with discussion with Steven on the list, let me urge not to have  
> the child name its parent but instead have the child name the  
> "interface" that its parents can consume.  Steven called is "offers"  
> and "uses";

Just for the record, I wan't calling it anything, I was using the  
words as verbs.  ;-)  If we're going to find a terminology for it, I  
like the idea of an unambiguous metaphor for something that connects  
to something else:

plug/socket
button/buttonhole
Tab A/Slot B
toast/toaster  ;-)

I don't know what, exactly, but "interfaces" is too broad -- unless  
you know what it is, you don't know what it is.  If it's named  
properly authors can have an idea of how they work just from the name.

Stephen
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Shane A. Froebel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I put the class file on trac if anyone wants to take a look at it.

http://core.trac.wordpress.org/ticket/10190

Your Friend,
Shane

scribu wrote:

> Ok, now I get what you were trying to say with "Interfaces".
>
> Yes, not using interfaces would would limit what could be done with
> their children, but on the other hand, interfaces would limit what
> child plugins could do themselves. It's a tradeoff.
>
> It's the same tradeoff that would happen if normal plugins would have
> to have an interface that the core would have to check.
>
> On 6/16/09, Mike Schinkel <mikeschinkel@...> wrote:
>> "scribu" <scribu@...> wrote:
>>> One or more child plugins can use functionality provided by one
>>> parent plugin. Parent plugins are not aware of the additional
>>> functionality that each child plugin provides. That's the basic
>>> model.
>> As with discussion with Steven on the list, let me urge not to have the
>> child name its parent but instead have the child name the "interface" that
>> its parents can consume.  Steven called is "offers" and "uses"; most any
>> terms will work but coupling children directly to parents will really limit
>> what can be done with their children and IMO would be a mistake.
>>
>> -Mike Schinkel
>> Custom Wordpress Plugins
>> http://mikeschinkel.com/custom-wordpress-plugins
>>
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers@...
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJKN8d4AAoJEChMcQvNqPqmT2sP/RPW7qSoVhv0aixFNl6DnPlN
RMvYLdDxLKG/Lh0Tjr/d4GZ39lth6K5AC9sXUgH4tIbRWJE4XSzl1PemjywuEm07
I8LIgLXuMcuB+iDAb3NiuMr32Vjfn1J3SgycOdfTPtbxpqxZchMaR31tLsYYFihk
+6o0QAfhIsvB9w9EsK2XSRUyI/sZ/CIZNbNyN2qIZ589Odw2r7XqyDCUtv+nbXCd
IxhHo24/gspjrLmLIuTzPcf2V0uVVGsydpJDBs7c0htnzYaY/JzzjrWqut9BERTV
8oom1rChv6cOTHIMXcCgpenlsc/5uENXvgK6a8onPdl38lSmCr5aMpq30jT+rhSD
u66KiXk6EQC2DWs4QXyeJYI9Lr39avEr/J1udLHR87KTIczuNgdmdL9+9lmvt+LI
Goil1c65oJNoMLTy74KD1OTO6c7ngBP3VyLfF1SxiYJcCLBTT3DGtW3yT7e6Q0GW
wxdRzmDy4Nihz6ZLukTC67bZpO0UB7JzlquOMgLQoeltfVg264w4Y6TB7KJEsz98
p0cc3Vo5x0tmhJFZuZ8OtEjZby9QDMrgHnoDg6C7F/C1NdHnQtve/4j4zz8w+6gE
9YaGwvX9DOgL3AUIJ5udIUaeYm+oRjkBRrTLoF+MYiUOp5JHTK/Ze9CkEEpXL4jL
FieqtBSiDIDm1NkLHV7G
=4dGN
-----END PGP SIGNATURE-----
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Stephen Rider]

On Jun 16, 2009, at 4:12 AM, Shane A. Froebel wrote:

> The way I have it "coded" right now is that when the plugin is even
> placed in WordPress it attaches itself to the 'register' part of the
> class so it can say 'Hello. I am installed and these are my  
> dependencies
> based on version of WordPress and Plugins Needed and their versions  
> for
> me to work properly.'


Certainly in the context of this thread, we have moved away from the  
idea of specifying plugin dependencies in favor of one plugin  
providing some sort of function that another plugin can look for.

Certainly within current WordPress plugins it is frowned upon to look  
for "WordPress version x.x"; instead coders are encouraged to look to  
see if a certain functionality exists.  This is because the latter is  
a more robust method.  For example I know that some people eliminate  
the WP Version string entirely for "security reasons" (aside: let's  
not get into arguments as to whether this is actually a security  
improvement!), but if a function exists, then it exists!

Mike Schinkel's argument is correct that even if I program a dependent  
plugin intending it to be used with "Plugin A", it might be entirely  
legitimate for someone to create "Plugin B" that can also use that  
"sub plugin".  This breaks if the sub plugin is checking for a  
specific "master"; but works just fine if the sub plugin says "I can  
do X for you" and the (any) master says "If any plugins can do X, do  
it now".

Stephen

--
Stephen Rider
http://striderweb.com/




_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Stephen Rider]

On Jun 15, 2009, at 12:44 AM, Mike Schinkel wrote:

> Dayum! I should have read ahead. I just wrote a ton and in this last  
> paragraph you essentially described interfaces.  So I deleted  
> everything that came before and am just sending this.

Heh.  Sorry about that.  I tried to warn you:

> You can read all of this for the discussion, or you may just choose  
> to jump to the bottom, where the rug gets yanked out from under....

Question for people who know more programming languages than I do:

Would it make sense to call these offered functions "services"?  Would  
this conflict with some other similar system that provides  
"services" (and uses that term)?

Stephen

--
Stephen Rider
http://striderweb.com/
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers