Class::MOP - A Meta Object Protocol for Perl 5
version 2.2203
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 to abide
by the spirit of the Perl 5 object system that we all know and love.
This documentation is sparse on conceptual details. We 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.
A meta object protocol is an API to an object system.
To be more specific, it abstracts the components of an object system (classes,
object, methods, object attributes, etc.). These abstractions can then be used
to 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.
Explicit MOPs are much less common, and depending on the language can vary
from restrictive (Reflection in Java or C#) to wide open (CLOS is a perfect
example).
This is
not a class builder so much as a
class builder
builder. The intent is that an end user will 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.
This system is used by Moose, which supplies a powerful class builder system
built entirely on top of "Class::MOP".
This module is for anyone who has ever created or wanted to create a module for
the Class:: namespace. The tools which this module provides make doing complex
Perl 5 wizardry simpler, by removing such barriers as the need to hack symbol
tables, or understand the fine details of method dispatch.
This module was designed to be as unobtrusive as possible. Many of its features
are accessible without
any change to your existing code. It is meant to
be a complement 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 require 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.
It is a common misconception that explicit MOPs are a performance hit. This is
not a universal truth, it is a side-effect of some specific implementations.
For instance, using Java reflection is slow 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 its 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.
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 metaclasses of the class's
ancestors.
Downward metaclass compatibility means that the metaclasses of a given class's
ancestors are all the same as (or a subclass of) that class's 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 |
+---------+ +---------+
In actuality,
all of a class's metaclasses must be compatible, not just
the class metaclass. That includes the instance, attribute, and method
metaclasses, as well as the constructor and destructor classes.
"Class::MOP" will attempt to fix some simple types of
incompatibilities. If all the metaclasses for the parent class are
subclasses of the child's metaclasses then we can simply replace the
child's metaclasses with the parent's. In addition, if the child is missing a
metaclass that the parent has, we can also just make the child use the
parent's metaclass.
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.
Always use the metaclass pragma when using a custom metaclass, this will ensure
the proper initialization order and not accidentally 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.
Note that if you're using Moose we encourage you to
not use the metaclass
pragma, and instead use Moose::Util::MetaRole to apply roles to a class's
metaclasses. This topic is covered at length in various Moose::Cookbook
recipes.
The meta-object protocol is divided into 4 main sub-protocols:
This provides a means of manipulating and introspecting a Perl 5 class. It
handles symbol table hacking for you, and provides a rich set of methods that
go beyond simple package introspection.
See Class::MOP::Class for more details.
This provides a consistent representation for an attribute of a Perl 5 class.
Since there are so many ways to create and handle attributes in Perl 5 OO, the
Attribute protocol provide as much of a unified approach as possible. Of
course, you are always free to extend this protocol by subclassing the
appropriate classes.
See Class::MOP::Attribute for more details.
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 Class::MOP::Method for more details.
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 reference to some other type of
reference. Several examples are provided in the
examples/ directory
included in this distribution.
See Class::MOP::Instance for more details.
Note that this module does not export any constants or functions.
Note that these are all called as
functions, not methods.
Class::MOP::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
determine where a given $code reference is from.
Class::MOP::class_of($instance_or_class_name)
This will return the metaclass of the given instance or class name. If the class
lacks a metaclass, no metaclass will be initialized, and "undef"
will be returned.
You should almost certainly be using "Moose::Util::find_meta" instead.
"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 these. Bad things could happen, but if you are
brave and willing to risk it: go for it!
Class::MOP::get_all_metaclasses
This will return a hash of all the metaclass instances that have been cached by
Class::MOP::Class, keyed by the package name.
Class::MOP::get_all_metaclass_instances
This will return a list of all the metaclass instances that have been cached by
Class::MOP::Class.
Class::MOP::get_all_metaclass_names
This will return a list of all the metaclass names that have been cached by
Class::MOP::Class.
Class::MOP::get_metaclass_by_name($name)
This will return a cached Class::MOP::Class instance, or nothing if no metaclass
exists with that $name.
Class::MOP::store_metaclass_by_name($name, $meta)
This will store a metaclass in the cache at the supplied $key.
Class::MOP::weaken_metaclass($name)
In rare cases (e.g. anonymous metaclasses) it is desirable to store a weakened
reference in the metaclass cache. This function will weaken the reference to
the metaclass stored in $name.
Class::MOP::metaclass_is_weak($name)
Returns true if the metaclass for $name has been weakened (via
"weaken_metaclass").
Class::MOP::does_metaclass_exist($name)
This will return true of there exists a metaclass stored in the $name key, and
return false otherwise.
Class::MOP::remove_metaclass_by_name($name)
This will remove the metaclass stored in the $name key.
Some utility functions (such as "Class::MOP::load_class") that were
previously defined in "Class::MOP" regarding loading of classes have
been extracted to Class::Load. Please see Class::Load for documentation.
There are very few books out on Meta Object Protocols and Metaclasses because it
is such an esoteric topic. The following books are really the only ones I have
found. If you know of any more,
please email me
and let me know, I would love to hear about them.
- The Art of the Meta Object Protocol
- Advances in Object-Oriented Metalevel Architecture and
Reflection
- Putting MetaClasses to Work
- Smalltalk: The Language
- "Uniform and safe metaclass composition"
- An excellent paper by the people who brought us the
original Traits paper. This paper is on how Traits can be used to do safe
metaclass composition, and offers an excellent introduction section which
delves into the topic of metaclass compatibility.
<http://scg.unibe.ch/archive/papers/Duca05ySafeMetaclassTrait.pdf>
- "Safe Metaclass Programming"
- This paper seems to precede the above paper, and propose a
mix-in based approach as opposed to the Traits based approach. Both papers
have similar information on the metaclass compatibility problem space.
<http://citeseer.ist.psu.edu/37617.html>
- The Perl 6 MetaModel work in the Pugs project
- CPAN Module Review of Class::MOP
- <http://www.oreillynet.com/onlamp/blog/2006/06/cpan_module_review_classmop.html>
As I have said above, this module is a class-builder-builder, so it is not the
same thing as modules like Class::Accessor and Class::MethodMaker. 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 Class::Meta, although its
philosophy and the MOP it creates are very different from this modules.
All complex software has bugs lurking in it, and this module is no exception.
Please report any bugs to "
[email protected]", or through the
web interface at <
http://rt.cpan.org>.
You can also discuss feature requests or possible bugs on the Moose mailing list
(
[email protected]) or on IRC at <irc://irc.perl.org/#moose>.
- Rob Kinyon
- Thanks to Rob for actually getting the development of this
module kick-started.
- •
- Stevan Little <[email protected]>
- •
- Dave Rolsky <[email protected]>
- •
- Jesse Luehrs <[email protected]>
- •
- Shawn M Moore <[email protected]>
- •
- יובל
קוג'מן (Yuval Kogman)
<[email protected]>
- •
- Karen Etheridge <[email protected]>
- •
- Florian Ragwitz <[email protected]>
- •
- Hans Dieter Pearcey <[email protected]>
- •
- Chris Prather <[email protected]>
- •
- Matt S Trout <[email protected]>
This software is copyright (c) 2006 by Infinity Interactive, Inc.
This is free software; you can redistribute it and/or modify it under the same
terms as the Perl 5 programming language system itself.