NAME

Object::Meta::Plugin::Host - 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

DESCRIPTION

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.

METHODS

Host

methods

Returns a hash ref, to a hash of methods => array refs. The array refs are the stacks, and they can be accessed individually via the stack method.

plug PLUGIN [ LIST ]

Takes a plugin, and calls it's init with the supplied arguments. The return value is then fed to register

plugins

Returns a hash ref, to a refhash. The keys are references to the plugins, and the values are export lists.

register EXPORTLIST

Takes an export list and integrates it's context into the method tree. The plugin the export list represents will be the topmost.

stack METHOD

Returns an array ref to a stack of plugins, for the method.

unplug PLUGIN [ PLUGIN ... ]

Takes a reference to a plugin, and sweeps the method tree clean of any of it's occurrences.

unregister EXPORTLIST [ EXPORTLIST ... ]

Takes an export list, and unmerges it from the currently active one. If it's empty, calls unplug. If something remains, it cleans out the stacks manually.

Context

self

plugin

Grants access to the actual plugin object which was passed via the export list. Use for internal storage space.

super

host

Grants access to the host object. Use $self-super->method> if you want to override the precedence of the current plugin.

next

prev

offset INTEGER

Generates a new context, having to do with a plugin n steps away from this, to a certain direction. next and prev call offset with -1 and 1 respectively. The offset object they return, has an autoloader which will search to see where the current plugin's instance is in the stack of a certain method, and then move a specified offset from that, and use the plugin in that slot.

CAVEATS

The can method (e.g. UNIVERSAL::can) is depended on. Without it everything will break. If you try to plug something nonstandard into a host, and export something UNIVERSAL::can won't say is there, implement can yourself.

BUGS

Just you wait. See TODO for what I have in stock!

TODO

• A better scheme for persistent data is needed, than $self-self> or $self-plugin>. It wreaks of lameness, and I fear it will be a psychological show stopper.

• Offset contexting AUTOLOADER needs to diet.

COPYRIGHT & LICENSE

Copyright 2003 Yuval Kogman. All rights reserved.
This program is free software; you can redistribute it
and/or modify it under the same terms as Perl itself.

AUTHOR

Yuval Kogman <nothingmuch@woobling.org>

SEE ALSO

Class::Classless, Class::Prototyped, Class::SelfMethods, Class::Object, and possibly Pipeline & Class::Dynamic.