Object::Meta::Plugin::Host 0.01

Object::Meta::Plugin::Host are hosts plugins that work like Object::Meta::Plugin. Can serve as a plugin if subclassed, or contains a plugin which can help it to plug.

SYNOPSIS

# if you want working examples, read basic.t in the distribution
# i dont know what kind of a synopsis would be useful for this.

my $host = new Object::Meta::Plugin::Host;

eval { $host->method() }; # should die

$host->plug($plugin); # $plugin defines method
$host->plug($another); # $another defines method and another

# $another supplied the following, since it was plugged in later
$host->method();
$host->another($argument);

$host->unplug($another);

$host->method(); # now $plugins method is used

Object::Meta::Plugin::Host is an implementation of a plugin host, as described in Object::Meta::Plugin.

The host is not just simply a merged hash. It is designed to allow various plugins to provide similar capabilities - methods with conflicting namespace. Conflicting namespaces can coexist, and take precedence over one another. A possible scenario is to have various plugins for an image processor, which all define the method "process". They are all installed, ordered as the effect should be taken out, and finally atop them all a plugin which wraps them into a pipeline is set.

When a plugins method is entered it receives, instead of the host object, a context object, particular to itself. It allows it access to its host, its sibling plugins, and so forth explicitly, while implicitly wrapping around the host, and emulating it with reordered priority - the current plugin is first in the list.

Such a model enables a dumb plugin to work quite happily with others, even those which may take its role. The only rule it needs to keep is that it accesses its data structures using $self-self>, and not $self, because $self is the context object.
A more complex plugin, aware that it may not be peerless, could explicitly ask for the default (host defined) methods it calls, instead of its own. It can request to call a method on the plugin which succeeds it or precedes it in a certain methods stack.

Additionally, by gaining access to the host object a plugin could implement a pipeline of calls quite easily, as described above. All it must do is call $self-host->stack($method)> and iterate that omitting itself.

The interface aims to be simple enough to be flexible, trying for the minimum it needs to define to be useful, and creating workarounds for the limitations this minimum imposes.

The implementation is by no means optimized. I doubt its fast, but I dont really care. Its supposed to create a nice framework for a large application, which needs to be modular.