/ 
Object-Meta-Plugin-0.02_04
River stage zero No dependents
/ Object::Meta::Plugin::Host

NAME

Object::Meta::Plugin::Host - Hosts plugins that work like Object::Meta::Plugin (Or rather Object::Meta::Plugin::Useful, because the prior doesn't work per se). Can be 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 illustrated in Object::Meta::Plugin.

The host is not just simply a merged namespace. It is designed to allow various plugins to provide similar capabilities - methods with conflicting namespace. Conflicting namespaces can coexist, and take precedence over, as well as access one another. An example scenario could be an image processor, whose various filter plugins all define the method "process". The plugins 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. It's process method will look like

sub process {
	my $self = shift;
	my $image = shift;
	
	foreach my $plugin (reverse @{ $self->super->stack('process') }){
		next if $plugin == $self->self;
		$image = $self->super->specific($plugin)->process($image);
	}
	
	# for (my $i = 1; $i <= $#{ $self->super->stack('process') }){
	#     $image = $self->offset($i)->process($image);
	# }
	
	return $image;
}

When a plugin's method is entered it receives, instead of the host object, a context object, particular to itself. The context object allows it access to the host host, the plugin's siblings, and so forth explicitly, while implicitly making one or two changes. The first is that all calls against $_[0], which is the context, are like calls to the host, but have an altered method priority - calls will be mapped to the current plugin's method before the host defaults methods. Moreover, plugin methods which are not installed in the host will also be accessible this way. The second, default but optional implicit change is that all modifications on the reference received in $_[0] are mapped via a tie interface or dereference overloading to the original plugin's data structures.

Such a model enables a dumb/lazy plugin to work quite happily with others, even those which may take it's role.

A more complex plugin, aware that it may not be peerless, could gain access to the host object, to it's original plugin object, could ask for offset method calls, and so forth.

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

METHODS

Host

methods

Returns a hash ref, to a hash of method names => 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.

specific PLUGIN

Returns a context object for a specific plugin. Like Context's next, prev, and offset, only with a plugin instead of an index.

stack METHOD

Returns an array ref to a stack of plugins, for the method. The last element is considered the topmost plugin, which is counter intuitive, considering offset works with higher indices being lower precedence.

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.

This behavior may change, as a plugin which has no active methods might still need be available.

Context

self
plugin

Grants access to the actual plugin object which was passed via the export list. Use for internal storage space. See CONTEXT STYLES (ACCESS TO PLUGIN INTERNALS).

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.

CONTEXT OBJECT STYLES (ACCESS TO PLUGIN INTERNALS)

The context shim styles are set by the object returned by the info method of the export list. Object::Meta::Plugin::ExportList will create an info object whose style method will return implicit by default.

You can override the info object by sending a new one to the export list constructor. Using the Useful:: implementations this can be acheived by sending the info object as the first argument to init. plug can do it for you:

my $i = new Object::Meta::Plugin::ExportList::Info;
$i->style('explicit');

$host->plug($plugin,$i);

Implicit

implicit
force-implicit

This style allows a plugin to pretend it's operating on itself.

The means to alow this are either by using overload or tie magic.

When the context object is overloaded, any operations on it will be performed on the original plugin object. Dereferencing, various operators overloaded in the plugin's implementations, and so forth should all work, because all operators will simply be delegated to the original plugin.

The only case where there is an exception, is if the plugin's structure is an array. Since the context is implemented as an array, the array dereference operator cannot be overloaded, nor can a plugin editing @$self get it's own data. Instead $self is a reference to a tied array. Operations on the tied array will be performed on the plugin's structures indirectly.

The implicit style comes in two flavors: implicit and force-implicit. The prior is the default. The latter will shut up warnings by Object::Meta::Plugin::Host on plug time. See DIAGNOSTIC for when this is desired.

If needed, $self-plugin> and $self-self> still work just as they do under the Explicit style.

Explicit

explicit

Using this style, the plugin will get the actual structure of the context shim, sans magic. If tied/overloaded access is inapplicable, that's the way to go. It's also more efficient under some scenarios.

In order to get access to the plugin structure the plugin must call $self-self> or $self-plugin>.

The explicit style gives the standard shim structure to the plugin. To gain access to it's structures a plugin will then need to call the method self on the shim, as documented in Object::Meta::Plugin::Host.

explicit is probably much more efficient when dereferencing a lot (overloading is not that fast, because it involves magic and an extra method call ($self-plugin> is simply called implicitly)), but is less programmer friendly. If you have a loop, like

for (my $i = 0; $i <= $bignumber; $i++){
	$self->{thing} = $i;
}

under the implicit style, it will be slow, because $self is overloaded every time. You can solve it by using

$ref = \%$self; # only if implicit is in use, and not on arrays

or by using

$ref = $self->plugin; # or $self->self

and operating on $ref instead of $self.

The aggregate functions (values, instead of each, for example) will not suffer greatly from operating on %$self.

As described in Implicit, arrays structures will benefit from explicit much more, because all operations on their contents is totally indirect.

C'est tout.

DIAGNOSIS

Errors

An error is emitted when the module doesn't know how to cope with a situation.

The offset is outside the bounds of the method stack for "%s"

The offset requested (via the methods next, prev or offset) is outside of the the stack of plugins for that method. That is, no plugin could be found that offset away from the current plugin.

Emitted at call time.

Can't locate object method "%s" via any plugin in %s

The method requested could not be found in any of the plugged in plugins. Instead of a classname, however, this error will report the host object's value.

Emitted at call time.

Method "%s" is reserved for use by the context object

The host AUTOLOADer was queried for a method defined in the context class. This is not a good thing, because it can cause unexpected behavior.

Emitted at plug or call time.

%s doesn't look like a plugin

The provided object's method can did not return a true value for init. This is what we define as a plugin for clarity.

Emitted at plug time.

%s doesn't look like a valid export list

The export list handed to the register method did not define all the necessary methods, as documented in Object::Meta::Plugin::ExportList.

Emitted at register time.

Can't locate object method "%s" via plugin %s

The method, requested for export by the export list, cannot be found via can within the plugin.

Emitted at register time.

%s is not plugged into %s

When requesting a specific plugin to be used, and the plugin doesn't exist this happens.

Emitted at specific time.

Unknown plugin style "%s" for %s

When a plugin's init method returns an object, whose info method returns an object, whose style method returns an unknown style, this is what happens.

Emitted at plug time.

Warnings

A warning is emitted when the internal functionality is expected to work, but the implications on external data (plugins) might be undesired from the programmer's standpoint.

You shouldn't use implicit access context shims if the underlying plugin's structure is already tied

If a plugin whose structure is a tied array is plugged, it must be wrapped in a tied array, so that a shim can be generated for it.

If the plugin is using it's structures in ways which extend beyond the array variable interface, that is anything having to do with tied, things will probably break.

Emitted at plug time.

Overloading a plugin's @{} operator will create unexpected behavior under the implicit style

When a plugin plugged with the implicit style has the @{} operator overloaded, this will cause funny things. If it attempts to dereference itself as an array the array will be the structure of the shim instead of what it was hoping for.

Emitted at plug time.

CAVEATS

  • 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 complex application. It's more efficient programming, not execution. This may be worked on a bit.

  • 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.

  • Constructing a plugin with a tied array as it's data structure, and using tied somewhere in the plugin will break. This is because when the plugin is an array ref, tieing is used to give the context shim storage space, while allowing implicit access to the plugin's data structure via the shim's data structure.

    If you do not explicitly ask for the tied style when plugging the plugin into the host, you will get a warning.

  • Using Scalar::Util's reftype on the context object will always return ARRAY, even if the plugin is not an array, and pretends the shim is not an array.

BUGS

  • The can method for the host implementation cannot return the code reference to the real subroutine which will eventually be called. This breaks hosts-as-plugins, because the plugged in host will have it's AUTOLOAD skipped.

    Using goto on the reference can returns will work, however.

TODO

  • 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.