{ "content": [ { "type": "text", "text": "# Moose::Manual::Concepts (perldoc)\n\n## NAME\n\nMoose::Manual::Concepts - Moose OO concepts\n\n## Sections\n\n- **NAME**\n- **VERSION** (12 subsections)\n- **AUTHORS**\n- **COPYRIGHT AND LICENSE**\n\nUse structuredContent.sections for detailed options, examples, and full documentation.\n" } ], "structuredContent": { "command": "Moose::Manual::Concepts", "section": "", "mode": "perldoc", "summary": "Moose::Manual::Concepts - Moose OO concepts", "synopsis": null, "tldr_summary": null, "tldr_examples": [], "tldr_source": null, "flags": [], "examples": [], "see_also": [], "section_outline": [ { "name": "NAME", "lines": 2, "subsections": [] }, { "name": "VERSION", "lines": 14, "subsections": [ { "name": "Class", "lines": 9 }, { "name": "superclass", "lines": 20 }, { "name": "Attribute", "lines": 26 }, { "name": "Method", "lines": 6 }, { "name": "Role", "lines": 43 }, { "name": "Method modifiers", "lines": 18 }, { "name": "Type", "lines": 9 }, { "name": "Delegation", "lines": 3 }, { "name": "Constructor", "lines": 10 }, { "name": "Destructor", "lines": 6 }, { "name": "Object instance", "lines": 10 }, { "name": "Moose vs old school summary", "lines": 127 } ] }, { "name": "AUTHORS", "lines": 20, "subsections": [] }, { "name": "COPYRIGHT AND LICENSE", "lines": 5, "subsections": [] } ], "sections": { "NAME": { "content": "Moose::Manual::Concepts - Moose OO concepts\n", "subsections": [] }, "VERSION": { "content": "version 2.2200\n\nMOOSE CONCEPTS (VS \"OLD SCHOOL\" Perl)\nIn the past, you may not have thought too much about the difference between packages and\nclasses, attributes and methods, constructors and methods, etc. With Moose, these are all\nconceptually separate, though under the hood they're implemented with plain old Perl.\n\nOur meta-object protocol (aka MOP) provides well-defined introspection features for each of\nthose concepts, and Moose in turn provides distinct sugar for each of them. Moose also\nintroduces additional concepts such as roles, method modifiers, and declarative delegation.\n\nKnowing what these concepts mean in Moose-speak, and how they used to be done in old school Perl\n5 OO is a good way to start learning to use Moose.\n", "subsections": [ { "name": "Class", "content": "When you say \"use Moose\" in a package, you are making your package a class. At its simplest, a\nclass will consist simply of attributes and/or methods. It can also include roles, method\nmodifiers, and more.\n\nA class *has* zero or more attributes.\n\nA class *has* zero or more methods.\n\nA class *has* zero or more superclasses (aka parent classes). A class inherits from its" }, { "name": "superclass", "content": "A class *has* zero or more method modifiers. These modifiers can apply to its own methods or\nmethods that are inherited from its ancestors.\n\nA class *does* (and *consumes*) zero or more roles.\n\nA class *has* a constructor and a destructor. These are provided for you \"for free\" by Moose.\n\nThe constructor accepts named parameters corresponding to the class's attributes and uses them\nto initialize an object instance.\n\nA class *has* a metaclass, which in turn has meta-attributes, meta-methods, and meta-roles. This\nmetaclass *describes* the class.\n\nA class is usually analogous to a category of nouns, like \"People\" or \"Users\".\n\npackage Person;\n\nuse Moose;\n# now it's a Moose class!\n" }, { "name": "Attribute", "content": "An attribute is a property of the class that defines it. It *always* has a name, and it *may\nhave* a number of other properties.\n\nThese properties can include a read/write flag, a type, accessor method names, delegations, a\ndefault value, and more.\n\nAttributes *are not* methods, but defining them causes various accessor methods to be created.\nAt a minimum, a normal attribute will have a reader accessor method. Many attributes have other\nmethods, such as a writer method, a clearer method, or a predicate method (\"has it been set?\").\n\nAn attribute may also define delegations, which will create additional methods based on the\ndelegation mapping.\n\nBy default, Moose stores attributes in the object instance, which is a hashref, *but this is\ninvisible to the author of a Moose-based class*! It is best to think of Moose attributes as\n\"properties\" of the *opaque* object instance. These properties are accessed through well-defined\naccessor methods.\n\nAn attribute is something that the class's members have. For example, People have first and last\nnames. Users have passwords and last login datetimes.\n\nhas 'firstname' => (\nis => 'rw',\nisa => 'Str',\n);\n" }, { "name": "Method", "content": "A method is very straightforward. Any subroutine you define in your class is a method.\n\nMethods correspond to verbs, and are what your objects can do. For example, a User can login.\n\nsub login { ... }\n" }, { "name": "Role", "content": "A role is something that a class *does*. We also say that classes *consume* roles. For example,\na Machine class might do the Breakable role, and so could a Bone class. A role is used to define\nsome concept that cuts across multiple unrelated classes, like \"breakability\", or \"has a color\".\n\nA role *has* zero or more attributes.\n\nA role *has* zero or more methods.\n\nA role *has* zero or more method modifiers.\n\nA role *has* zero or more required methods.\n\nA required method is not implemented by the role. Required methods are a way for the role to\ndeclare \"to use this role you must implement this method\".\n\nA role *has* zero or more excluded roles.\n\nAn excluded role is a role that the role doing the excluding says it cannot be combined with.\n\nRoles are *composed* into classes (or other roles). When a role is composed into a class, its\nattributes and methods are \"flattened\" into the class. Roles *do not* show up in the inheritance\nhierarchy. When a role is composed, its attributes and methods appear as if they were defined\n*in the consuming class*.\n\nRole are somewhat like mixins or interfaces in other OO languages.\n\npackage Breakable;\n\nuse Moose::Role;\n\nrequires 'break';\n\nhas 'isbroken' => (\nis => 'rw',\nisa => 'Bool',\n);\n\nafter 'break' => sub {\nmy $self = shift;\n\n$self->isbroken(1);\n};\n" }, { "name": "Method modifiers", "content": "A method modifier is a hook that is called when a named method is called. For example, you could\nsay \"before calling \"login()\", call this modifier first\". Modifiers come in different flavors\nlike \"before\", \"after\", \"around\", and \"augment\", and you can apply more than one modifier to a\nsingle method.\n\nMethod modifiers are often used as an alternative to overriding a method in a parent class. They\nare also used in roles as a way of modifying methods in the consuming class.\n\nUnder the hood, a method modifier is just a plain old Perl subroutine that gets called before or\nafter (or around, etc.) some named method.\n\nbefore 'login' => sub {\nmy $self = shift;\nmy $pw = shift;\n\nwarn \"Called login() with $pw\\n\";\n};\n" }, { "name": "Type", "content": "Moose also comes with a (miniature) type system. This allows you to define types for attributes.\nMoose has a set of built-in types based on the types Perl provides in its core, such as \"Str\",\n\"Num\", \"Bool\", \"HashRef\", etc.\n\nIn addition, every class name in your application can also be used as a type name.\n\nFinally, you can define your own types with their own constraints. For example, you could define\na \"PosInt\" type, a subtype of \"Int\" which only allows positive numbers.\n" }, { "name": "Delegation", "content": "Moose attributes provide declarative syntax for defining delegations. A delegation is a method\nwhich in turn calls some method on an attribute to do its real work.\n" }, { "name": "Constructor", "content": "A constructor creates an object instance for the class. In old school Perl, this was usually\ndone by defining a method called \"new()\" which in turn called \"bless\" on a reference.\n\nWith Moose, this \"new()\" method is created for you, and it simply does the right thing. You\nshould never need to define your own constructor!\n\nSometimes you want to do something whenever an object is created. In those cases, you can\nprovide a \"BUILD()\" method in your class. Moose will call this for you after creating a new\nobject.\n" }, { "name": "Destructor", "content": "This is a special method called when an object instance goes out of scope. You can specialize\nwhat your class does in this method if you need to, but you usually don't.\n\nWith old school Perl 5, this is the \"DESTROY()\" method, but with Moose it is the \"DEMOLISH()\"\nmethod.\n" }, { "name": "Object instance", "content": "An object instance is a specific noun in the class's \"category\". For example, one specific\nPerson or User. An instance is created by the class's constructor.\n\nAn instance has values for its attributes. For example, a specific person has a first and last\nname.\n\nIn old school Perl 5, this is often a blessed hash reference. With Moose, you should never need\nto know what your object instance actually is. (Okay, it's usually a blessed hashref with Moose,\ntoo.)\n" }, { "name": "Moose vs old school summary", "content": "* Class\n\nA package with no introspection other than mucking about in the symbol table.\n\nWith Moose, you get well-defined declaration and introspection.\n\n* Attributes\n\nHand-written accessor methods, symbol table hackery, or a helper module like\n\"Class::Accessor\".\n\nWith Moose, these are declaratively defined, and distinct from methods.\n\n* Method\n\nThese are pretty much the same in Moose as in old school Perl.\n\n* Roles\n\n\"Class::Trait\" or \"Class::Role\", or maybe \"mixin.pm\".\n\nWith Moose, they're part of the core feature set, and are introspectable like everything\nelse.\n\n* Method Modifiers\n\nCould only be done through serious symbol table wizardry, and you probably never saw this\nbefore (at least in Perl 5).\n\n* Type\n\nHand-written parameter checking in your \"new()\" method and accessors.\n\nWith Moose, you define types declaratively, and then use them by name with your attributes.\n\n* Delegation\n\n\"Class::Delegation\" or \"Class::Delegator\", but probably even more hand-written code.\n\nWith Moose, this is also declarative.\n\n* Constructor\n\nA \"new()\" method which calls \"bless\" on a reference.\n\nComes for free when you define a class with Moose.\n\n* Destructor\n\nA \"DESTROY()\" method.\n\nWith Moose, this is called \"DEMOLISH()\".\n\n* Object Instance\n\nA blessed reference, usually a hash reference.\n\nWith Moose, this is an opaque thing which has a bunch of attributes and methods, as defined\nby its class.\n\n* Immutabilization\n\nMoose comes with a feature called \"immutabilization\". When you make your class immutable, it\nmeans you're done adding methods, attributes, roles, etc. This lets Moose optimize your\nclass with a bunch of extremely dirty in-place code generation tricks that speed up things\nlike object construction and so on.\n\nMETA WHAT?\nA metaclass is a class that describes classes. With Moose, every class you define gets a\n\"meta()\" method. The \"meta()\" method returns a Moose::Meta::Class object, which has an\nintrospection API that can tell you about the class it represents.\n\nmy $meta = User->meta();\n\nfor my $attribute ( $meta->getallattributes ) {\nprint $attribute->name(), \"\\n\";\n\nif ( $attribute->hastypeconstraint ) {\nprint \" type: \", $attribute->typeconstraint->name, \"\\n\";\n}\n}\n\nfor my $method ( $meta->getallmethods ) {\nprint $method->name, \"\\n\";\n}\n\nAlmost every concept we defined earlier has a meta class, so we have Moose::Meta::Class,\nMoose::Meta::Attribute, Moose::Meta::Method, Moose::Meta::Role, Moose::Meta::TypeConstraint,\nMoose::Meta::Instance, and so on.\n\nBUT I NEED TO DO IT MY WAY!\nOne of the great things about Moose is that if you dig down and find that it does something the\n\"wrong way\", you can change it by extending a metaclass. For example, you can have arrayref\nbased objects, you can make your constructors strict (no unknown parameters allowed!), you can\ndefine a naming scheme for attribute accessors, you can make a class a Singleton, and much, much\nmore.\n\nMany of these extensions require surprisingly small amounts of code, and once you've done it\nonce, you'll never have to hand-code \"your way of doing things\" again. Instead you'll just load\nyour favorite extensions.\n\npackage MyWay::User;\n\nuse Moose;\nuse MooseX::StrictConstructor;\nuse MooseX::MyWay;\n\nhas ...;\n\nWHAT NEXT?\nSo you're sold on Moose. Time to learn how to really use it.\n\nIf you want to see how Moose would translate directly into old school Perl 5 OO code, check out\nMoose::Manual::Unsweetened. This might be helpful for quickly wrapping your brain around some\naspects of \"the Moose way\".\n\nOr you can skip that and jump straight to Moose::Manual::Classes and the rest of the\nMoose::Manual.\n\nAfter that we recommend that you start with the Moose::Cookbook. If you work your way through\nall the recipes under the basics section, you should have a pretty good sense of how Moose\nworks, and all of its basic OO features.\n\nAfter that, check out the Role recipes. If you're really curious, go on and read the Meta and\nExtending recipes, but those are mostly there for people who want to be Moose wizards and extend\nMoose itself.\n" } ] }, "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": [] } } } }