Author image יובל קוג'מן (Yuval Kogman)


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


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



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.


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.


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:


        # ...


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

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. The context provides a more comfortable environment for the plugin, while maintaining a relationship to the host, external of the plugin itself. 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 is the one sole method needed to consider an object to be a plugin. Ofcourse, it must also return a proper value. 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 way to access your plugin's data structures, and thus gain data store, is $self->self. That's a silly way. I need to find some easier method of accessing the guts of the plugin. Perhaps with tied hashes, but that sounds very dirty.

  • There's a huge dependancy on every plugin implementing can if UNIVERSAL::can won't work for it. Just do it.


        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.


Yuval Kogman <>


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.