Страницы справочника OS X

Эта страница руководства для  версии 10.9 Mac OS X

Читать страницы руководства

Class::MOP(3)                        User Contributed Perl Documentation                       Class::MOP(3)



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

VERSION
       version 2.0205

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

       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.

   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.

   Utility functions
       Note that these are all called as functions, not methods.

       Class::MOP::load_class($class_name, \%options?)
           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.

           You can pass a hash reference with options as second argument. The only option currently
           recognized is "-version", which will ensure that the loaded class has at least the required
           version.

           For historical reasons, this function explicitly returns a true value.

       Class::MOP::is_class_loaded($class_name, \%options?)
           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.

           You can pass a hash reference with options as second argument. The only option currently
           recognized is "-version", which will ensure that the loaded class has at least the required
           version.

       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.

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

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/misc/Perl-
           MetaModel/>
           http://github .com/perl6/p5-modules/tree/master/Perl6-ObjectSpace/
           <http://github.com/perl6/p5-modules/tree/master/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 its 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@rt.cpan.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@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.

AUTHOR
       Stevan Little <stevan@iinteractive.com>

COPYRIGHT AND LICENSE
       This software is copyright (c) 2011 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.



perl v5.12.5                                     2011-09-06                                    Class::MOP(3)