On Apache
Under GNU General Public License
2012-02-09 13:47 @38.107.179.239 Crawled by CCBot/1.0 (+http://www.commoncrawl.org/bot.html)
Class::MOP(3pm) User Contributed Perl Documentation Class::MOP(3pm)
NAME
Class::MOP - A Meta Object Protocol for Perl 5
DESCRIPTION
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.
What is a Meta Object Protocol?
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).
Yet Another Class Builder! Why?
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".
Who is this module for?
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.
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 existing code. 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.
About Performance
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.
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 ancestors
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 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 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.
PROTOCOLS
The meta-object 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 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.
The Attribute protocol
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.
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 Class::MOP::Method 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 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.
FUNCTIONS
Note that this module does not export any constants or functions.
Constants
Class::MOP::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 compatible.
Utility functions
Note that these are all called as functions, not methods.
Class::MOP::load_class($class_name)
This will load the specified $class_name, if it is not already loaded (as reported by
"is_class_loaded"). This function can be used in place of tricks like "eval "use
$module"" or using "require" unconditionally.
If the module cannot be loaded, an exception is thrown.
For historical reasons, this function explicitly returns a true value.
Class::MOP::is_class_loaded($class_name)
Returns a boolean indicating whether or not $class_name has been loaded.
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, but it can be
fooled into reporting false positives. In particular, loading any of the core IO
modules will cause most of the rest of the core IO modules to falsely report having
been loaded, due to the way the base IO module works.
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.
Class::MOP::check_package_cache_flag($pkg)
NOTE: DO NOT USE THIS FUNCTION, IT IS FOR INTERNAL USE ONLY!
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.
Class::MOP::load_first_existing_class(@class_names)
NOTE: DO NOT USE THIS FUNCTION, IT IS FOR INTERNAL USE ONLY!
Given a list of class names, this function will attempt to load each one in turn.
If it finds a class it can load, it will return that class' name. If none of the
classes can be loaded, it will throw an exception.
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 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::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.
SEE ALSO
Books
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
Papers
"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://www.iam.unibe.ch/~scg/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>
Prior Art
The Perl 6 MetaModel work in the Pugs project
<http://svn.openfoundry.org/pugs/misc/Perl-MetaModel/>
<http://svn.openfoundry.org/pugs/perl5/Perl6-ObjectSpace>
Articles
CPAN Module Review of Class::MOP
<http://www.oreillynet.com/onlamp/blog/2006/06/cpan_module_review_classmop.html>
SIMILAR MODULES
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 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.
Please report any bugs to "bug-class-mop AT rt.org", or through the web interface at
<http://rt.cpan.org>.
You can also discuss feature requests or possible bugs on the Moose mailing list
(moose AT perl.org) or on IRC at <irc://irc.perl.org/#moose>.
ACKNOWLEDGEMENTS
Rob Kinyon
Thanks to Rob for actually getting the development of this module kick-started.
AUTHORS
Stevan Little <stevan AT iinteractive.com>
with contributions from:
Brandon (blblack) Black
Florian (rafl) Ragwitz
Guillermo (groditi) Roditi
Dave (autarch) Rolsky
Matt (mst) Trout
Rob (robkinyon) Kinyon
Yuval (nothingmuch) Kogman
Scott (konobi) McWhirter
Dylan Hardison
COPYRIGHT AND LICENSE
Copyright 2006-2009 by Infinity Interactive, Inc.
<http://www.iinteractive.com>
This library is free software; you can redistribute it and/or modify it under the same
terms as Perl itself.
perl v5.10.0 2009-12-18 Class::MOP(3pm)
Generated by $Id: phpMan.php,v 4.49 2006/02/26 13:18:18 chedong Exp $ Author: Che Dong
On Apache
Under GNU General Public License
2012-02-09 13:47 @38.107.179.239 Crawled by CCBot/1.0 (+http://www.commoncrawl.org/bot.html)