{ "mode": "perldoc", "parameter": "Class::MOP", "section": "", "url": "https://www.chedong.com/phpMan.php/perldoc/Class%3A%3AMOP/json", "generated": "2026-05-30T06:25:34Z", "sections": { "NAME": { "content": "Class::MOP - A Meta Object Protocol for Perl 5\n", "subsections": [] }, "VERSION": { "content": "version 2.2200\n", "subsections": [] }, "DESCRIPTION": { "content": "This module is a fully functioning meta object protocol for the Perl 5\nobject system. It makes no attempt to change the behavior or\ncharacteristics of the Perl 5 object system, only to create a protocol\nfor its manipulation and introspection.\n\nThat said, it does attempt to create the tools for building a rich set\nof extensions to the Perl 5 object system. Every attempt has been made\nto abide by the spirit of the Perl 5 object system that we all know and\nlove.\n\nThis documentation is sparse on conceptual details. We suggest looking\nat the items listed in the \"SEE ALSO\" section for more information. In\nparticular the book \"The Art of the Meta Object Protocol\" was very\ninfluential in the development of this system.\n\nWhat is a Meta Object Protocol?\nA meta object protocol is an API to an object system.\n\nTo be more specific, it abstracts the components of an object system\n(classes, object, methods, object attributes, etc.). These abstractions\ncan then be used to inspect and manipulate the object system which they\ndescribe.\n\nIt can be said that there are two MOPs for any object system; the\nimplicit MOP and the explicit MOP. The implicit MOP handles things like\nmethod dispatch or inheritance, which happen automatically as part of\nhow the object system works. The explicit MOP typically handles the\nintrospection/reflection features of the object system.\n\nAll object systems have implicit MOPs. Without one, they would not work.\nExplicit MOPs are much less common, and depending on the language can\nvary from restrictive (Reflection in Java or C#) to wide open (CLOS is a\nperfect example).\n\nYet Another Class Builder! Why?\nThis is not a class builder so much as a *class builder builder*. The\nintent is that an end user will not use this module directly, but\ninstead this module is used by module authors to build extensions and\nfeatures onto the Perl 5 object system.\n\nThis system is used by Moose, which supplies a powerful class builder\nsystem built entirely on top of \"Class::MOP\".\n\nWho is this module for?\nThis module is for anyone who has ever created or wanted to create a\nmodule for the Class:: namespace. The tools which this module provides\nmake doing complex Perl 5 wizardry simpler, by removing such barriers as\nthe need to hack symbol tables, or understand the fine details of method\ndispatch.\n\nWhat changes do I have to make to use this module?\nThis module was designed to be as unobtrusive as possible. Many of its\nfeatures are accessible without any change to your existing code. It is\nmeant to be a complement to your existing code and not an intrusion on\nyour code base. Unlike many other Class:: modules, this module does not\nrequire you subclass it, or even that you \"use\" it in within your\nmodule's package.\n\nThe only features which require additions to your code are the attribute\nhandling and instance construction features, and these are both\ncompletely optional features. The only reason for this is because Perl\n5's object system does not actually have these features built in. More\ninformation about this feature can be found below.\n", "subsections": [ { "name": "About Performance", "content": "It is a common misconception that explicit MOPs are a performance hit.\nThis is not a universal truth, it is a side-effect of some specific\nimplementations. For instance, using Java reflection is slow because the\nJVM cannot take advantage of any compiler optimizations, and the JVM has\nto deal with much more runtime type information as well.\n\nReflection in C# is marginally better as it was designed into the\nlanguage and runtime (the CLR). In contrast, CLOS (the Common Lisp\nObject System) was built to support an explicit MOP, and so performance\nis tuned for it.\n\nThis library in particular does its absolute best to avoid putting any\ndrain at all upon your code's performance. In fact, by itself it does\nnothing to affect your existing code. So you only pay for what you\nactually use.\n" }, { "name": "About Metaclass compatibility", "content": "This module makes sure that all metaclasses created are both upwards and\ndownwards compatible. The topic of metaclass compatibility is highly\nesoteric and is something only encountered when doing deep and involved\nmetaclass hacking. There are two basic kinds of metaclass\nincompatibility; upwards and downwards.\n\nUpwards metaclass compatibility means that the metaclass of a given\nclass is either the same as (or a subclass of) all of the metaclasses of\nthe class's ancestors.\n\nDownward metaclass compatibility means that the metaclasses of a given\nclass's ancestors are all the same as (or a subclass of) that class's\nmetaclass.\n\nHere is a diagram showing a set of two classes (\"A\" and \"B\") and two\nmetaclasses (\"Meta::A\" and \"Meta::B\") which have correct metaclass\ncompatibility both upwards and downwards.\n\n+---------+ +---------+\n| Meta::A |<----| Meta::B | <....... (instance of )\n+---------+ +---------+ <------- (inherits from)\n^ ^\n: :\n+---------+ +---------+\n| A |<----| B |\n+---------+ +---------+\n\nIn actuality, *all* of a class's metaclasses must be compatible, not\njust the class metaclass. That includes the instance, attribute, and\nmethod metaclasses, as well as the constructor and destructor classes.\n\n\"Class::MOP\" will attempt to fix some simple types of incompatibilities.\nIf all the metaclasses for the parent class are *subclasses* of the\nchild's metaclasses then we can simply replace the child's metaclasses\nwith the parent's. In addition, if the child is missing a metaclass that\nthe parent has, we can also just make the child use the parent's\nmetaclass.\n\nAs I said this is a highly esoteric topic and one you will only run into\nif you do a lot of subclassing of Class::MOP::Class. If you are\ninterested in why this is an issue see the paper *Uniform and safe\nmetaclass composition* linked to in the \"SEE ALSO\" section of this\ndocument.\n" }, { "name": "Using custom metaclasses", "content": "Always use the metaclass pragma when using a custom metaclass, this will\nensure the proper initialization order and not accidentally create an\nincorrect type of metaclass for you. This is a very rare problem, and\none which can only occur if you are doing deep metaclass programming. So\nin other words, don't worry about it.\n\nNote that if you're using Moose we encourage you to *not* use the\nmetaclass pragma, and instead use Moose::Util::MetaRole to apply roles\nto a class's metaclasses. This topic is covered at length in various\nMoose::Cookbook recipes.\n" } ] }, "PROTOCOLS": { "content": "The meta-object protocol is divided into 4 main sub-protocols:\n", "subsections": [ { "name": "The Class protocol", "content": "This provides a means of manipulating and introspecting a Perl 5 class.\nIt handles symbol table hacking for you, and provides a rich set of\nmethods that go beyond simple package introspection.\n\nSee Class::MOP::Class for more details.\n" }, { "name": "The Attribute protocol", "content": "This provides a consistent representation for an attribute of a Perl 5\nclass. Since there are so many ways to create and handle attributes in\nPerl 5 OO, the Attribute protocol provide as much of a unified approach\nas possible. Of course, you are always free to extend this protocol by\nsubclassing the appropriate classes.\n\nSee Class::MOP::Attribute for more details.\n" }, { "name": "The Method protocol", "content": "This provides a means of manipulating and introspecting methods in the\nPerl 5 object system. As with attributes, there are many ways to\napproach this topic, so we try to keep it pretty basic, while still\nmaking it possible to extend the system in many ways.\n\nSee Class::MOP::Method for more details.\n" }, { "name": "The Instance protocol", "content": "This provides a layer of abstraction for creating object instances.\nSince the other layers use this protocol, it is relatively easy to\nchange the type of your instances from the default hash reference to\nsome other type of reference. Several examples are provided in the\nexamples/ directory included in this distribution.\n\nSee Class::MOP::Instance for more details.\n" } ] }, "FUNCTIONS": { "content": "Note that this module does not export any constants or functions.\n", "subsections": [ { "name": "Utility functions", "content": "Note that these are all called as functions, not methods.\n\nClass::MOP::getcodeinfo($code)\nThis function returns two values, the name of the package the $code is\nfrom and the name of the $code itself. This is used by several elements\nof the MOP to determine where a given $code reference is from.\n\nClass::MOP::classof($instanceorclassname)\nThis will return the metaclass of the given instance or class name. If\nthe class lacks a metaclass, no metaclass will be initialized, and\n\"undef\" will be returned.\n\nYou should almost certainly be using \"Moose::Util::findmeta\" instead.\n" }, { "name": "Metaclass cache functions", "content": "\"Class::MOP\" holds a cache of metaclasses. The following are functions\n(not methods) which can be used to access that cache. It is not\nrecommended that you mess with these. Bad things could happen, but if\nyou are brave and willing to risk it: go for it!\n\nClass::MOP::getallmetaclasses\nThis will return a hash of all the metaclass instances that have been\ncached by Class::MOP::Class, keyed by the package name.\n\nClass::MOP::getallmetaclassinstances\nThis will return a list of all the metaclass instances that have been\ncached by Class::MOP::Class.\n\nClass::MOP::getallmetaclassnames\nThis will return a list of all the metaclass names that have been cached\nby Class::MOP::Class.\n\nClass::MOP::getmetaclassbyname($name)\nThis will return a cached Class::MOP::Class instance, or nothing if no\nmetaclass exists with that $name.\n\nClass::MOP::storemetaclassbyname($name, $meta)\nThis will store a metaclass in the cache at the supplied $key.\n\nClass::MOP::weakenmetaclass($name)\nIn rare cases (e.g. anonymous metaclasses) it is desirable to store a\nweakened reference in the metaclass cache. This function will weaken the\nreference to the metaclass stored in $name.\n\nClass::MOP::metaclassisweak($name)\nReturns true if the metaclass for $name has been weakened (via\n\"weakenmetaclass\").\n\nClass::MOP::doesmetaclassexist($name)\nThis will return true of there exists a metaclass stored in the $name\nkey, and return false otherwise.\n\nClass::MOP::removemetaclassbyname($name)\nThis will remove the metaclass stored in the $name key.\n\nSome utility functions (such as \"Class::MOP::loadclass\") that were\npreviously defined in \"Class::MOP\" regarding loading of classes have\nbeen extracted to Class::Load. Please see Class::Load for documentation.\n" } ] }, "SEE ALSO": { "content": "", "subsections": [ { "name": "Books", "content": "There are very few books out on Meta Object Protocols and Metaclasses\nbecause it is such an esoteric topic. The following books are really the\nonly ones I have found. If you know of any more, *please* email me and\nlet me know, I would love to hear about them.\n\n*The Art of the Meta Object Protocol*\n*Advances in Object-Oriented Metalevel Architecture and Reflection*\n*Putting MetaClasses to Work*\n*Smalltalk: The Language*\n" }, { "name": "Papers", "content": "\"Uniform and safe metaclass composition\"\nAn excellent paper by the people who brought us the original Traits\npaper. This paper is on how Traits can be used to do safe metaclass\ncomposition, and offers an excellent introduction section which\ndelves into the topic of metaclass compatibility.\n\n\n\n\"Safe Metaclass Programming\"\nThis paper seems to precede the above paper, and propose a mix-in\nbased approach as opposed to the Traits based approach. Both papers\nhave similar information on the metaclass compatibility problem\nspace.\n\n\n" }, { "name": "Prior Art", "content": "The Perl 6 MetaModel work in the Pugs project\n\n\n" }, { "name": "Articles", "content": "CPAN Module Review of Class::MOP\n\n" } ] }, "SIMILAR MODULES": { "content": "As I have said above, this module is a class-builder-builder, so it is\nnot the same thing as modules like Class::Accessor and\nClass::MethodMaker. That being said there are very few modules on CPAN\nwith similar goals to this module. The one I have found which is most\nlike this module is Class::Meta, although its philosophy and the MOP it\ncreates are very different from this modules.\n", "subsections": [] }, "BUGS": { "content": "All complex software has bugs lurking in it, and this module is no\nexception.\n\nPlease report any bugs to \"bug-class-mop@rt.cpan.org\", or through the\nweb interface at .\n\nYou can also discuss feature requests or possible bugs on the Moose\nmailing list (moose@perl.org) or on IRC at .\n", "subsections": [] }, "ACKNOWLEDGEMENTS": { "content": "Rob Kinyon\nThanks to Rob for actually getting the development of this module\nkick-started.\n", "subsections": [] }, "AUTHORS": { "content": "* Stevan Little \n\n* Dave Rolsky \n\n* Jesse Luehrs \n\n* Shawn M Moore \n\n* יובל קוג'מן (Yuval Kogman) \n\n* Karen Etheridge \n\n* Florian Ragwitz \n\n* Hans Dieter Pearcey \n\n* Chris Prather \n\n* Matt S Trout \n", "subsections": [] }, "COPYRIGHT AND LICENSE": { "content": "This software is copyright (c) 2006 by Infinity Interactive, Inc.\n\nThis is free software; you can redistribute it and/or modify it under\nthe same terms as the Perl 5 programming language system itself.\n", "subsections": [] } }, "summary": "Class::MOP - A Meta Object Protocol for Perl 5", "flags": [], "examples": [], "see_also": [] }