{ "content": [ { "type": "text", "text": "# Class::MOP (perldoc)\n\n## NAME\n\nClass::MOP - A Meta Object Protocol for Perl 5\n\n## DESCRIPTION\n\nThis module is a fully functioning meta object protocol for the Perl 5 object system. It makes\nno attempt to change the behavior or characteristics of the Perl 5 object system, only to create\na protocol for its manipulation and introspection.\n\n## Sections\n\n- **NAME**\n- **VERSION**\n- **DESCRIPTION** (3 subsections)\n- **PROTOCOLS** (4 subsections)\n- **FUNCTIONS** (2 subsections)\n- **SEE ALSO** (4 subsections)\n- **SIMILAR MODULES**\n- **BUGS**\n- **ACKNOWLEDGEMENTS**\n- **AUTHORS**\n- **COPYRIGHT AND LICENSE**\n\nUse structuredContent.sections for detailed options, examples, and full documentation.\n" } ], "structuredContent": { "command": "Class::MOP", "section": "", "mode": "perldoc", "summary": "Class::MOP - A Meta Object Protocol for Perl 5", "synopsis": null, "tldr_summary": null, "tldr_examples": [], "tldr_source": null, "flags": [], "examples": [], "see_also": [], "section_outline": [ { "name": "NAME", "lines": 2, "subsections": [] }, { "name": "VERSION", "lines": 2, "subsections": [] }, { "name": "DESCRIPTION", "lines": 53, "subsections": [ { "name": "About Performance", "lines": 13 }, { "name": "About Metaclass compatibility", "lines": 36 }, { "name": "Using custom metaclasses", "lines": 9 } ] }, { "name": "PROTOCOLS", "lines": 2, "subsections": [ { "name": "The Class protocol", "lines": 5 }, { "name": "The Attribute protocol", "lines": 7 }, { "name": "The Method protocol", "lines": 6 }, { "name": "The Instance protocol", "lines": 7 } ] }, { "name": "FUNCTIONS", "lines": 2, "subsections": [ { "name": "Utility functions", "lines": 13 }, { "name": "Metaclass cache functions", "lines": 40 } ] }, { "name": "SEE ALSO", "lines": 1, "subsections": [ { "name": "Books", "lines": 9 }, { "name": "Papers", "lines": 14 }, { "name": "Prior Art", "lines": 4 }, { "name": "Articles", "lines": 3 } ] }, { "name": "SIMILAR MODULES", "lines": 6, "subsections": [] }, { "name": "BUGS", "lines": 8, "subsections": [] }, { "name": "ACKNOWLEDGEMENTS", "lines": 3, "subsections": [] }, { "name": "AUTHORS", "lines": 20, "subsections": [] }, { "name": "COPYRIGHT AND LICENSE", "lines": 5, "subsections": [] } ], "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 object system. It makes\nno attempt to change the behavior or characteristics of the Perl 5 object system, only to create\na protocol for its manipulation and introspection.\n\nThat said, it does attempt to create the tools for building a rich set of extensions to the Perl\n5 object system. Every attempt has been made to abide by the spirit of the Perl 5 object system\nthat we all know and love.\n\nThis documentation is sparse on conceptual details. We suggest looking at the items listed in\nthe \"SEE ALSO\" section for more information. In particular the book \"The Art of the Meta Object\nProtocol\" was very influential 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 (classes, object, methods,\nobject attributes, etc.). These abstractions can then be used to inspect and manipulate the\nobject system which they describe.\n\nIt can be said that there are two MOPs for any object system; the implicit MOP and the explicit\nMOP. The implicit MOP handles things like method dispatch or inheritance, which happen\nautomatically as part of how 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. Explicit MOPs are much\nless common, and depending on the language can vary from restrictive (Reflection in Java or C#)\nto wide open (CLOS is a perfect example).\n\nYet Another Class Builder! Why?\nThis is not a class builder so much as a *class builder builder*. The intent is that an end user\nwill not use this module directly, but instead this module is used by module authors to build\nextensions and features onto the Perl 5 object system.\n\nThis system is used by Moose, which supplies a powerful class builder system built entirely on\ntop of \"Class::MOP\".\n\nWho is this module for?\nThis module is for anyone who has ever created or wanted to create a module for the Class::\nnamespace. The tools which this module provides make doing complex Perl 5 wizardry simpler, by\nremoving such barriers as the need to hack symbol tables, or understand the fine details of\nmethod dispatch.\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 features are accessible\nwithout any change to your existing code. It is meant to be a complement to your existing code\nand not an intrusion on your code base. Unlike many other Class:: modules, this module does not\nrequire you subclass it, or even that you \"use\" it in within your module's package.\n\nThe only features which require additions to your code are the attribute handling and instance\nconstruction features, and these are both completely optional features. The only reason for this\nis because Perl 5'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. This is not a universal\ntruth, it is a side-effect of some specific implementations. For instance, using Java reflection\nis slow because the JVM cannot take advantage of any compiler optimizations, and the JVM has to\ndeal with much more runtime type information as well.\n\nReflection in C# is marginally better as it was designed into the language and runtime (the\nCLR). In contrast, CLOS (the Common Lisp Object System) was built to support an explicit MOP,\nand so performance is tuned for it.\n\nThis library in particular does its absolute best to avoid putting any drain at all upon your\ncode's performance. In fact, by itself it does nothing to affect your existing code. So you only\npay for what you actually use.\n" }, { "name": "About Metaclass compatibility", "content": "This module makes sure that all metaclasses created are both upwards and downwards compatible.\nThe topic of metaclass compatibility is highly esoteric and is something only encountered when\ndoing deep and involved metaclass hacking. There are two basic kinds of metaclass\nincompatibility; upwards and downwards.\n\nUpwards metaclass compatibility means that the metaclass of a given class is either the same as\n(or a subclass of) all of the metaclasses of the class's ancestors.\n\nDownward metaclass compatibility means that the metaclasses of a given class's ancestors are all\nthe same as (or a subclass of) that class's metaclass.\n\nHere is a diagram showing a set of two classes (\"A\" and \"B\") and two metaclasses (\"Meta::A\" and\n\"Meta::B\") which have correct metaclass compatibility 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 just the class metaclass.\nThat includes the instance, attribute, and method metaclasses, as well as the constructor and\ndestructor classes.\n\n\"Class::MOP\" will attempt to fix some simple types of incompatibilities. If all the metaclasses\nfor the parent class are *subclasses* of the child's metaclasses then we can simply replace the\nchild's metaclasses with the parent's. In addition, if the child is missing a metaclass that the\nparent has, we can also just make the child use the parent's metaclass.\n\nAs I said this is a highly esoteric topic and one you will only run into if you do a lot of\nsubclassing of Class::MOP::Class. If you are interested in why this is an issue see the paper\n*Uniform and safe metaclass composition* linked to in the \"SEE ALSO\" section of this document.\n" }, { "name": "Using custom metaclasses", "content": "Always use the metaclass pragma when using a custom metaclass, this will ensure the proper\ninitialization order and not accidentally create an incorrect type of metaclass for you. This is\na very rare problem, and one which can only occur if you are doing deep metaclass programming.\nSo in other words, don't worry about it.\n\nNote that if you're using Moose we encourage you to *not* use the metaclass pragma, and instead\nuse Moose::Util::MetaRole to apply roles to a class's metaclasses. This topic is covered at\nlength in various Moose::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. It handles symbol table\nhacking for you, and provides a rich set of methods 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 class. Since there are so\nmany ways to create and handle attributes in Perl 5 OO, the Attribute protocol provide as much\nof a unified approach as 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 Perl 5 object system. As\nwith attributes, there are many ways to approach this topic, so we try to keep it pretty basic,\nwhile still making 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. Since the other layers use\nthis protocol, it is relatively easy to change the type of your instances from the default hash\nreference to some other type of reference. Several examples are provided in the examples/\ndirectory 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 from and the name of the\n$code itself. This is used by several elements of the MOP to determine where a given $code\nreference is from.\n\nClass::MOP::classof($instanceorclassname)\nThis will return the metaclass of the given instance or class name. If the class lacks a\nmetaclass, no metaclass will be initialized, and \"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 (not methods) which can\nbe used to access that cache. It is not recommended that you mess with these. Bad things could\nhappen, but if you 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 cached by\nClass::MOP::Class, keyed by the package name.\n\nClass::MOP::getallmetaclassinstances\nThis will return a list of all the metaclass instances that have been cached by\nClass::MOP::Class.\n\nClass::MOP::getallmetaclassnames\nThis will return a list of all the metaclass names that have been cached by Class::MOP::Class.\n\nClass::MOP::getmetaclassbyname($name)\nThis will return a cached Class::MOP::Class instance, or nothing if no metaclass exists with\nthat $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 weakened reference in the\nmetaclass cache. This function will weaken the reference to the metaclass stored in $name.\n\nClass::MOP::metaclassisweak($name)\nReturns true if the metaclass for $name has been weakened (via \"weakenmetaclass\").\n\nClass::MOP::doesmetaclassexist($name)\nThis will return true of there exists a metaclass stored in the $name key, and return false\notherwise.\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 previously defined in\n\"Class::MOP\" regarding loading of classes have been extracted to Class::Load. Please see\nClass::Load for documentation.\n" } ] }, "SEE ALSO": { "content": "", "subsections": [ { "name": "Books", "content": "There are very few books out on Meta Object Protocols and Metaclasses because it is such an\nesoteric topic. The following books are really the only ones I have found. If you know of any\nmore, *please* email me and let 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 paper. This paper is on\nhow Traits can be used to do safe metaclass composition, and offers an excellent\nintroduction section which delves 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 based approach as opposed\nto the Traits based approach. Both papers have similar information on the metaclass\ncompatibility problem space.\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 not the same thing as\nmodules like Class::Accessor and Class::MethodMaker. That being said there are very few modules\non CPAN with similar goals to this module. The one I have found which is most like this module\nis Class::Meta, although its philosophy and the MOP it creates are very different from this\nmodules.\n", "subsections": [] }, "BUGS": { "content": "All complex software has bugs lurking in it, and this module is no exception.\n\nPlease report any bugs to \"bug-class-mop@rt.cpan.org\", or through the web interface at\n.\n\nYou can also discuss feature requests or possible bugs on the Moose mailing list\n(moose@perl.org) or on IRC at .\n", "subsections": [] }, "ACKNOWLEDGEMENTS": { "content": "Rob Kinyon\nThanks to Rob for actually getting the development of this module kick-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 the same terms as the Perl\n5 programming language system itself.\n", "subsections": [] } } } }