Section: User Contributed Perl Documentation (3)
Moose::Cookbook - How to cook a Moose
The Moose cookbook is a series of recipes showing various Moose
features. Most recipes present some code demonstrating some feature,
and then explain the details of the code.
You should probably read the Moose::Manual first. The manual
explains Moose concepts without being too code-heavy.
These recipes will give you a good overview of Moose's capabilities, starting
with simple attribute declaration, and moving on to more powerful features like
laziness, types, type coercion, method modifiers, and more.
A simple Moose-based class. Demonstrates basic Moose attributes and subclassing.
A slightly more complex Moose class. Demonstrates using a method modifier in a
Demonstrates several attribute features, including types, weak
references, predicates (``does this object have a foo?''), defaults,
laziness, and triggers.
Introduces the creation and use of custom types, a "BUILD" method, and the
use of "override" in a subclass. This recipe also shows how to model a set of
classes that could be used to model companies, people, employees, etc.
This recipe covers more subtype creation, including the use of type coercions.
Making a class immutable greatly increases the speed of accessors and
- Moose::Cookbook::Basics::BinaryTree_BuilderAndLazyBuild - Builder methods and lazy_build
The builder feature provides an inheritable and role-composable way to
provide a default attribute value.
Demonstrates using operator overloading, coercion, and subtypes to
model how eye color is determined during reproduction.
This recipe demonstrates the use of "BUILDARGS" and "BUILD" to hook
into object construction.
In this recipe, we make a Moose-based subclass of DateTime, a
module which does not use Moose itself.
Demonstrates the use of "augment" method modifiers, a way of turning
the usual method overriding style ``inside-out''.
These recipes will show you how to use Moose roles.
Demonstrates roles, which are also sometimes known as traits or
mix-ins. Roles provide a method of code re-use which is orthogonal to
Sometimes you just want to include part of a role in your
class. Sometimes you want the whole role but one of its methods
conflicts with one in your class. With method exclusion and aliasing,
you can work around these problems.
In this recipe, we apply a role to an existing object instance.
These recipes show you how to write your own meta classes, which lets
you extend the object system provided by Moose.
If you're wondering what all this ``meta'' stuff is, and why you should
care about it, read this ``recipe''.
Extending Moose's attribute metaclass is a great way to add
functionality. However, attributes can only have one metaclass.
Applying roles to the attribute metaclass lets you provide
composable attribute functionality.
This recipe takes the class metaclass we saw in the previous recipe
and reimplements it as a metaclass trait.
This recipe shows a custom method metaclass that implements making a
This recipe shows an example of how you create your own meta-instance
class. The meta-instance determines the internal structure of object
instances and provide access to attribute slots.
In this particular instance, we use a blessed glob reference as the instance
instead of a blessed hash reference.
- Hooking into immutabilization (TODO)
Moose has a feature known as ``immutabilization''. By calling "__PACKAGE__->meta()->make_immutable()" after defining your class
(attributes, roles, etc), you tell Moose to optimize things like
object creation, attribute access, and so on.
If you are creating your own metaclasses, you may need to hook into
the immutabilization system. This cuts across a number of spots,
including the metaclass class, meta method classes, and possibly the
meta-instance class as well.
This recipe shows you how to write extensions which immutabilize
These recipes cover some more ways to extend Moose, and will be useful
if you plan to write your own "MooseX"
There are quite a few ways to extend Moose. This recipe provides an
overview of each method, and provides recommendations for when each is
Many base object class extensions can be implemented as roles. This
example shows how to provide a base object class debugging role that
is applied to any class that uses a notional "MooseX::Debugging"
This recipe shows how to provide a replacement for "Moose.pm". You
may want to do this as part of the API for a "MooseX" module,
especially if you want to default to a new metaclass class or base
These cover topics that are no longer considered best practice. We've kept
them in case in you encounter these usages in the wild.
Stevan Little <email@example.com>
Dave Rolsky <firstname.lastname@example.org>
Jesse Luehrs <email@example.com>
Shawn M Moore <firstname.lastname@example.org>
יובל קוג'מן (Yuval Kogman) <email@example.com>
Karen Etheridge <firstname.lastname@example.org>
Florian Ragwitz <email@example.com>
Hans Dieter Pearcey <firstname.lastname@example.org>
Chris Prather <email@example.com>
Matt S Trout <firstname.lastname@example.org>
COPYRIGHT AND LICENSE
This software is copyright (c) 2006 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.