Class::MOP - A Meta Object Protocol for Perl 5

What is a Meta Object Protocol?
Yet Another Class Builder!! Why?
Who is this module for?
What changes do I have to make to use this module?
A Note about Performance?
About Metaclass compatibility
Using custom metaclasses

PROTOCOLS
FUNCTIONS

Constants
Utility functions
Metaclass cache functions

SEE ALSO

Books
Papers
Prior Art
Articles

SIMILAR MODULES
BUGS
ACKNOWLEDGEMENTS
AUTHORS
COPYRIGHT AND LICENSE

NAME

Class::MOP - A Meta Object Protocol for Perl 5

DESCRIPTON

This module is a fully functioning meta object protocol for the Perl 5 object system. It makes no attempt to change the behavior or characteristics of the Perl 5 object system, only to create a protocol for its manipulation and introspection.

That said, it does attempt to create the tools for building a rich set of extensions to the Perl 5 object system. Every attempt has been made for these tools to keep to the spirit of the Perl 5 object system that we all know and love.

This documentation is admittedly sparse on details, as time permits I will try to improve them. For now, I suggest looking at the items listed in the SEE ALSO section for more information. In particular the book ``The Art of the Meta Object Protocol'' was very influential in the development of this system.

What is a Meta Object Protocol?

A meta object protocol is an API to an object system.

To be more specific, it is a set of abstractions of the components of an object system (typically things like; classes, object, methods, object attributes, etc.). These abstractions can then be used to both inspect and manipulate the object system which they describe.

It can be said that there are two MOPs for any object system; the implicit MOP, and the explicit MOP. The implicit MOP handles things like method dispatch or inheritance, which happen automatically as part of how the object system works. The explicit MOP typically handles the introspection/reflection features of the object system. All object systems have implicit MOPs, without one, they would not work. Explict MOPs however as less common, and depending on the language can vary from restrictive (Reflection in Java or C#) to wide open (CLOS is a perfect example).

Yet Another Class Builder!! Why?

This is not a class builder so much as it is a class builder builder. My intent is that an end user does not use this module directly, but instead this module is used by module authors to build extensions and features onto the Perl 5 object system.

Who is this module for?

This module is specifically for anyone who has ever created or wanted to create a module for the Class:: namespace. The tools which this module will provide will hopefully make it easier to do more complex things with Perl 5 classes by removing such barriers as the need to hack the symbol tables, or understand the fine details of method dispatch.

What changes do I have to make to use this module?

This module was designed to be as unintrusive as possible. Many of its features are accessible without any change to your existsing code at all. It is meant to be a compliment to your existing code and not an intrusion on your code base. Unlike many other Class:: modules, this module does not require you subclass it, or even that you use it in within your module's package.

The only features which requires additions to your code are the attribute handling and instance construction features, and these are both completely optional features. The only reason for this is because Perl 5's object system does not actually have these features built in. More information about this feature can be found below.

A Note about Performance?

It is a common misconception that explict MOPs are performance drains. But this is not a universal truth at all, it is an side-effect of specific implementations. For instance, using Java reflection is much slower because the JVM cannot take advantage of any compiler optimizations, and the JVM has to deal with much more runtime type information as well. Reflection in C# is marginally better as it was designed into the language and runtime (the CLR). In contrast, CLOS (the Common Lisp Object System) was built to support an explicit MOP, and so performance is tuned for it.

This library in particular does it's absolute best to avoid putting any drain at all upon your code's performance. In fact, by itself it does nothing to affect your existing code. So you only pay for what you actually use.

About Metaclass compatibility

This module makes sure that all metaclasses created are both upwards and downwards compatible. The topic of metaclass compatibility is highly esoteric and is something only encountered when doing deep and involved metaclass hacking. There are two basic kinds of metaclass incompatibility; upwards and downwards.

Upwards metaclass compatibility means that the metaclass of a given class is either the same as (or a subclass of) all of the class's ancestors.

Downward metaclass compatibility means that the metaclasses of a given class's anscestors are all either the same as (or a subclass of) that metaclass.

Here is a diagram showing a set of two classes (A and B) and two metaclasses (Meta::A and Meta::B) which have correct metaclass compatibility both upwards and downwards.

    +---------+     +---------+
    | Meta::A |<----| Meta::B |      <....... (instance of  )
    +---------+     +---------+      <------- (inherits from)
         ^               ^
         :               :
    +---------+     +---------+
    |    A    |<----|    B    |
    +---------+     +---------+

As I said this is a highly esoteric topic and one you will only run into if you do a lot of subclassing of Class::MOP::Class. If you are interested in why this is an issue see the paper Uniform and safe metaclass composition linked to in the SEE ALSO section of this document.

Using custom metaclasses

Always use the metaclass pragma when using a custom metaclass, this will ensure the proper initialization order and not accidentely create an incorrect type of metaclass for you. This is a very rare problem, and one which can only occur if you are doing deep metaclass programming. So in other words, don't worry about it.

PROTOCOLS

The protocol is divided into 4 main sub-protocols:

The Class protocol: This provides a means of manipulating and introspecting a Perl 5 class. It handles all of symbol table hacking for you, and provides a rich set of methods that go beyond simple package introspection.; See the Class::MOP::Class manpage for more details.
The Attribute protocol: This provides a consistent represenation for an attribute of a Perl 5 class. Since there are so many ways to create and handle attributes in Perl 5 OO, this attempts to provide as much of a unified approach as possible, while giving the freedom and flexibility to subclass for specialization.; See the Class::MOP::Attribute manpage for more details.
The Method protocol: This provides a means of manipulating and introspecting methods in the Perl 5 object system. As with attributes, there are many ways to approach this topic, so we try to keep it pretty basic, while still making it possible to extend the system in many ways.; See the Class::MOP::Method manpage for more details.
The Instance protocol: This provides a layer of abstraction for creating object instances. Since the other layers use this protocol, it is relatively easy to change the type of your instances from the default HASH ref to other types of references. Several examples are provided in the examples/ directory included in this distribution.; See the Class::MOP::Instance manpage for more details.

FUNCTIONS

Constants

IS_RUNNING_ON_5_10: We set this constant depending on what version perl we are on, this allows us to take advantage of new 5.10 features and stay backwards compat.

Utility functions

load_class ($class_name): This will load a given $class_name and if it does not have an already initialized metaclass, then it will intialize one for it. This function can be used in place of tricks like eval "use $module" or using require.
is_class_loaded ($class_name): This will return a boolean depending on if the $class_name has been loaded.; NOTE: This does a basic check of the symbol table to try and determine as best it can if the $class_name is loaded, it is probably correct about 99% of the time.
check_package_cache_flag ($pkg): This will return an integer that is managed by Class::MOP::Class to determine if a module's symbol table has been altered.; In Perl 5.10 or greater, this flag is package specific. However in versions prior to 5.10, this will use the PL_sub_generation variable which is not package specific.
get_code_info ($code): This function returns two values, the name of the package the $code is from and the name of the $code itself. This is used by several elements of the MOP to detemine where a given $code reference is from.

Metaclass cache functions

Class::MOP holds a cache of metaclasses, the following are functions (not methods) which can be used to access that cache. It is not recommended that you mess with this, bad things could happen. But if you are brave and willing to risk it, go for it.

get_all_metaclasses: This will return an hash of all the metaclass instances that have been cached by Class::MOP::Class keyed by the package name.
get_all_metaclass_instances: This will return an array of all the metaclass instances that have been cached by Class::MOP::Class.
get_all_metaclass_names: This will return an array of all the metaclass names that have been cached by Class::MOP::Class.
get_metaclass_by_name ($name): This will return a cached Class::MOP::Class instance of nothing if no metaclass exist by that $name.
store_metaclass_by_name ($name, $meta): This will store a metaclass in the cache at the supplied $key.
weaken_metaclass ($name): In rare cases it is desireable to store a weakened reference in the metaclass cache. This function will weaken the reference to the metaclass stored in $name.
does_metaclass_exist ($name): This will return true of there exists a metaclass stored in the $name key and return false otherwise.
remove_metaclass_by_name ($name): This will remove a the metaclass stored in the $name key.

SIMILAR MODULES

As I have said above, this module is a class-builder-builder, so it is not the same thing as modules like the Class::Accessor manpage and the Class::MethodMaker manpage. That being said there are very few modules on CPAN with similar goals to this module. The one I have found which is most like this module is the Class::Meta manpage, although it's philosophy and the MOP it creates are very different from this modules.

BUGS

All complex software has bugs lurking in it, and this module is no exception. If you find a bug please either email me, or add the bug to cpan-RT.

ACKNOWLEDGEMENTS

Rob Kinyon: Thanks to Rob for actually getting the development of this module kick-started.

AUTHORS

Stevan Little <stevan@iinteractive.com>

with contributions from:

Brandon (blblack) Black

Guillermo (groditi) Roditi

Matt (mst) Trout

Rob (robkinyon) Kinyon

Yuval (nothingmuch) Kogman

Scott (konobi) McWhirter

COPYRIGHT AND LICENSE

http://www.iinteractive.com

This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.

Class::MOP - A Meta Object Protocol for Perl 5