From: James Edward Gray II <james@...>
Date: 2010-03-22T03:44:05+09:00
Subject: Re: A plugin system using extend

On Mar 21, 2010, at 1:35 PM, Robert Klemme wrote:

> On 03/21/2010 06:14 PM, James Edward Gray II wrote:
>> On Mar 21, 2010, at 2:13 AM, Jean-denis Vauguet wrote:
>>> Another idea I had is the following:
>>> - any loaded lugin registers as a "callback" for the classes it wants to alter (instances of the classes, actually!);
>>> - through the Plugins module, which is mix-ined within the Base module using :extend, have any class nested within the base module to be able (forced?), everytime they're initialized, to have their instances :extend the plugins which have registered as callback for the class.
>>> 
>>> Not really sure about it, but...
>>> Theoretically it would allow for per-instance :extend, thus overriding behavior of any instance without the need for aliasing. Same behavior as my standalone and Josh codes, but same flexibility as my previous gist attempted to achieve.
>>> 
>>> I'll give it a try when I get the time to, unless I'm told this is BS ;)
>> If I understand what you are saying correctly, I've used this exact strategy in the past.
>> I allowed plugins to register themselves on the class object (you can also do that automatically as they are defined with an inherited hook), and then I just extended all instances with the registered plugins as they were created.
>> It worked great and felt very natural to me when using it.
> 
> James, what's the advantage of this over simply using "include"?  If all instances get to use the plugin module then you can as well include it in the class.

There's one massive advantage:  the inheritance order.  include puts the plugin behind the base class, which is much less useful than extend's behavior of putting it in front of the base class (behind the singleton class, technically).  To me, this is the very reason this system is so natural for plugins.

James Edward Gray II