Object::Meta::Plugin::Host 0.01 review

Object::Meta::Plugin::Host are hosts plugins that work like Object::Meta::Plugin

License: Perl Artistic License File size: 0K Developer: Yuval Kogman

0

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 don't 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 $plugin's 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 plugin's method is entered it receives, instead of the host object, a context object, particular to itself. It allows it access to it's host, it's 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 it's role. The only rule it needs to keep is that it accesses it's 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 it's own. It can request to call a method on the plugin which succeeds it or precedes it in a certain method's 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 it's fast, but I don't really care. It's supposed to create a nice framework for a large application, which needs to be modular.

Requirements:
Perl