{ "content": [ { "type": "text", "text": "# Moose::Manual::Construction (perldoc)\n\n## NAME\n\nMoose::Manual::Construction - Object construction (and destruction) with Moose\n\n## Sections\n\n- **NAME**\n- **VERSION**\n- **OBJECT CONSTRUCTION AND ATTRIBUTES**\n- **OBJECT CONSTRUCTION HOOKS**\n- **OBJECT DESTRUCTION** (1 subsections)\n- **AUTHORS**\n- **COPYRIGHT AND LICENSE**\n\nUse structuredContent.sections for detailed options, examples, and full documentation.\n" } ], "structuredContent": { "command": "Moose::Manual::Construction", "section": "", "mode": "perldoc", "summary": "Moose::Manual::Construction - Object construction (and destruction) with Moose", "synopsis": null, "tldr_summary": null, "tldr_examples": [], "tldr_source": null, "flags": [], "examples": [], "see_also": [], "section_outline": [ { "name": "NAME", "lines": 2, "subsections": [] }, { "name": "VERSION", "lines": 10, "subsections": [] }, { "name": "OBJECT CONSTRUCTION AND ATTRIBUTES", "lines": 5, "subsections": [] }, { "name": "OBJECT CONSTRUCTION HOOKS", "lines": 90, "subsections": [] }, { "name": "OBJECT DESTRUCTION", "lines": 11, "subsections": [ { "name": "Error Handling During Destruction", "lines": 14 } ] }, { "name": "AUTHORS", "lines": 20, "subsections": [] }, { "name": "COPYRIGHT AND LICENSE", "lines": 5, "subsections": [] } ], "sections": { "NAME": { "content": "Moose::Manual::Construction - Object construction (and destruction) with Moose\n", "subsections": [] }, "VERSION": { "content": "version 2.2200\n\nWHERE'S THE CONSTRUCTOR?\nDo not define a \"new()\" method for your classes!\n\nWhen you \"use Moose\" in your class, your class becomes a subclass of Moose::Object. The\nMoose::Object provides a \"new()\" method for your class. If you follow our recommendations in\nMoose::Manual::BestPractices and make your class immutable, then you actually get a\nclass-specific \"new()\" method \"inlined\" in your class.\n", "subsections": [] }, "OBJECT CONSTRUCTION AND ATTRIBUTES": { "content": "The Moose-provided constructor accepts a hash or hash reference of named parameters matching\nyour attributes (actually, matching their \"initarg\"s). This is just another way in which Moose\nkeeps you from worrying *how* classes are implemented. Simply define a class and you're ready to\nstart creating objects!\n", "subsections": [] }, "OBJECT CONSTRUCTION HOOKS": { "content": "Moose lets you hook into object construction. You can validate an object's state, do logging,\ncustomize construction from parameters which do not match your attributes, or maybe allow\nnon-hash(ref) constructor arguments. You can do this by creating \"BUILD\" and/or \"BUILDARGS\"\nmethods.\n\nIf these methods exist in your class, Moose will arrange for them to be called as part of the\nobject construction process.\n\nBUILDARGS\nThe \"BUILDARGS\" method is called as a class method *before* an object is created. It will\nreceive all of the arguments that were passed to \"new()\" *as-is*, and is expected to return a\nhash reference. This hash reference will be used to construct the object, so it should contain\nkeys matching your attributes' names (well, \"initarg\"s).\n\nOne common use for \"BUILDARGS\" is to accommodate a non-hash(ref) calling style. For example, we\nmight want to allow our Person class to be called with a single argument of a social security\nnumber, \"Person->new($ssn)\".\n\nWithout a \"BUILDARGS\" method, Moose will complain, because it expects a hash or hash reference.\nWe can use the \"BUILDARGS\" method to accommodate this calling style:\n\naround BUILDARGS => sub {\nmy $orig = shift;\nmy $class = shift;\n\nif ( @ == 1 && !ref $[0] ) {\nreturn $class->$orig( ssn => $[0] );\n}\nelse {\nreturn $class->$orig(@);\n}\n};\n\nNote the call to \"$class->$orig\". This will call the default \"BUILDARGS\" in Moose::Object. This\nmethod takes care of distinguishing between a hash reference and a plain hash for you.\n\nBUILD\nThe \"BUILD\" method is called *after* an object is created. There are several reasons to use a\n\"BUILD\" method. One of the most common is to check that the object state is valid. While we can\nvalidate individual attributes through the use of types, we can't validate the state of a whole\nobject that way.\n\nsub BUILD {\nmy $self = shift;\n\nif ( $self->countryofresidence eq 'USA' ) {\ndie 'All US residents must have an SSN'\nunless $self->hasssn;\n}\n}\n\nAnother use of a \"BUILD\" method could be for logging or tracking object creation.\n\nsub BUILD {\nmy $self = shift;\n\ndebug( 'Made a new person - SSN = ', $self->ssn, );\n}\n\nThe \"BUILD\" method is called with the hash reference of the parameters passed to the constructor\n(after munging by \"BUILDARGS\"). This gives you a chance to do something with parameters that do\nnot represent object attributes.\n\nsub BUILD {\nmy $self = shift;\nmy $args = shift;\n\n$self->addfriend(\nMy::User->new(\nuserid => $args->{userid},\n)\n);\n}\n\nBUILD and parent classes\nThe interaction between multiple \"BUILD\" methods in an inheritance hierarchy is different from\nnormal Perl methods. You should never call \"$self->SUPER::BUILD\", nor should you ever apply a\nmethod modifier to \"BUILD\". Roles are an exception to this rule, though: it's completely\nacceptable to apply a method modifier to \"BUILD\" in a role; you can even provide an empty\n\"BUILD\" subroutine in a role so the role is applicable even to classes without their own\n\"BUILD\".\n\nMoose arranges to have all of the \"BUILD\" methods in a hierarchy called when an object is\nconstructed, *from parents to children*. This might be surprising at first, because it reverses\nthe normal order of method inheritance.\n\nThe theory behind this is that \"BUILD\" methods can only be used for increasing specialization of\na class's constraints, so it makes sense to call the least specific \"BUILD\" method first. Also,\nthis is how Perl 6 does it.\n", "subsections": [] }, "OBJECT DESTRUCTION": { "content": "Moose provides a hook for object destruction with the \"DEMOLISH\" method. As with \"BUILD\", you\nshould never explicitly call \"$self->SUPER::DEMOLISH\". Moose will arrange for all of the\n\"DEMOLISH\" methods in your hierarchy to be called, from most to least specific.\n\nEach \"DEMOLISH\" method is called with a single argument. This is a boolean value indicating\nwhether or not this method was called as part of the global destruction process (when the Perl\ninterpreter exits).\n\nIn most cases, Perl's built-in garbage collection is sufficient, and you won't need to provide a\n\"DEMOLISH\" method.\n", "subsections": [ { "name": "Error Handling During Destruction", "content": "The interaction of object destruction and Perl's global $@ and $? variables can be very\nconfusing.\n\nMoose always localizes $? when an object is being destroyed. This means that if you explicitly\ncall \"exit\", that exit code will be preserved even if an object's destructor makes a system\ncall.\n\nMoose also preserves $@ against any \"eval\" calls that may happen during object destruction.\nHowever, if an object's \"DEMOLISH\" method actually dies, Moose explicitly rethrows that error.\n\nIf you do not like this behavior, you will have to provide your own \"DESTROY\" method and use\nthat instead of the one provided by Moose::Object. You can do this to preserve $@ *and* capture\nany errors from object destruction by creating an error stack.\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": [] } } } }