NAME

Object::Meta::Plugin - A classless compound object implementation or a base class for an element of thereof.

SYNOPSIS

# Read on please. Examples are in Object::Meta::Plugin::Host.

DESCRIPTION

Distribution

The Object::Meta::Plugin distribution is an implementation of a classless object system, which bases itself on plugins. An object implemented with it is a meta object, because it is modifiable during runtime, attaching and detaching pieces of itself, which we will call plugins. The overlying object will inherit, in a way, from the underlying objects.

Class

The Object::Meta::Plugin class is a very slim base class which defines the mandatory methods needed for a plugin to be considered a plugin. It is extended by the Object::Meta::Plugin::Useful variants, which are a group of useful plugin base classes, that you can use to easily construct plugins that work, and not just sit there.

Due to the somewhat lacking nature of the class Object::Meta::Plugin, I will devote the rest of this document to general information regarding the distribution, returning to the class as needed.

CONCEPT

The basic concept is that you have an object. The object is quite empty and dull, and defines some methods using it's own real class - amongst them are plug, and unplug. These methods are used to connect a plugin to the host, and disconnect it from the host:

$host->plug($plugin);

# ...

$host->unplug($plugin);

When an object is plugged into the host it's init method is called, with the arguments that were passed to plug just after the plugin object itself. What init needs to do is tell the host what to import into it. It does this by means of an export list object. The definition of such an object, as well as a simple reference implementation, can be found in Object::Meta::Plugin::ExportList.

In fact, plug does nothing of it's own right. It simply passes the return value from init to register. You could use some sort of handle object to plug into the host - the actual reference which will be accounted for, is that which is returned by the export list object's method plugin.

The host object will use the register method to register the plugin's methods in it's indices. Plugins will thus stack atop one another, similar to the way classes subclass other classes. But it doesn't need to be that way, since the method stacks can be reordered arbitrarily - they're just arrays of references.

Subsequently, a method not defined by the host's class (or ancestors, but not in my implementation) will be called. The host's AUTOLOAD subroutine will then take action. If the method which was not found is exported by any of the plugged plugins a croak will be uttered. Otherwise, the host will create what is known as a context object (a sort of shim). The context provides a more comfortable environment for the plugin, while maintaining a relationship to the host, without changing anything in the plugin's data structures (no reblessing, etc). It also enables some additional whiz bang, like having the methods next and prev work even if multiple copies of the same plugin are attached at various points in the host.

It should be noted that the host implementation was designed so that it could be plugged into another host, provided a plugin of some sort will provide the basic definition of a plugin. This "meta plugin" thing is illustrated in Object::Meta::Plugin::Useful::Meta, and tested for in the test suite.

METHODS (OF THE CLASS NAMED HEREIN)

init

This is the one sole method needed to consider an object to be a plugin. Of course, it must also return a proper valuem, which looks like an Object::Meta::Plugin::ExportList. In this implementation it simply croaks. You need to use an Object::Meta::Plugin::Useful variant if you don't want to write it all yourself.

The expected behavior is documented in Object::Meta::Plugin::Host, which is the ultimate authority on what needs to happen.

CAVEATS

• There's a huge dependency on every plugin's can method. If UNIVERSAL::can won't work for it, just implement it.

BUGS

Conceptually I think there's no room for bugs here, because what it defines it defines as "the right way". Look at the implementation.

TODO

• Create general multimethod/dispatcher plugin base classes.

• Audit docs.

• Write a short tutorial on plugin writing.

• Extend test suite at the specific level. More accurate testing must be made.

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

Object::Meta::Plugin::Host, Object::Meta::Plugin::Useful, Object::Meta::Plugin::ExportList, Class::Classless, Class::Prototyped, Class::SelfMethods, Class::Object, and possibly Pipeline & Class::Dynamic.