This says that all C<Person> objects have an optional read-write
"first_name" attribute.
-=head2 Read-write Vs Read-only
+=head2 Read-write Vs read-only
The options passed to C<has> define the properties of the
attribute. There are a many options, but in the simplest form you just
that has no accessors, which is pointless unless you're doing some
deep, dark magic).
-=head2 Accessor Methods
+=head2 Accessor methods
Each attribute has one or more accessor methods. An accessor lets you
read and write the value of that attribute for an object.
extension system that lets override the default naming
conventions. See L<Moose::Manual::MooseX> for more details.
-=head2 Predicate and Clearer Methods
+=head2 Predicate and clearer methods
Moose allows you to explicitly distinguish between a false or
undefined attribute value and an attribute which has not been set. If
By default, Moose does not make a predicate or clearer for you. You
must explicitly provide names for them.
-=head2 Required or Not?
+=head2 Required or not?
By default, all attributes are optional, and do not need to be
provided at object construction time. If you want to make an attribute
have a I<private> C<clearer> and C<predicate> for a required
attribute.
-=head2 Default and Builder Methods
+=head2 Default and builder methods
Attributes can have default values, and Moose provides two ways to
specify that default.
We strongly recommend that you use a C<builder> instead of a
C<default> for anything beyond the most trivial default.
-=head2 Laziness and lazy_build
+=head2 Laziness and C<lazy_build>
Moose lets you defer attribute population by making an attribute
C<lazy>:
Options that you explicitly provide are always used in favor of
Moose's internal defaults.
-=head2 Constructor Parameters (init_arg)
+=head2 Constructor parameters (C<init_arg>)
By default, each attribute can be passed by name to the class's
constructor. On occasion, you may want to use a different name for
By setting the C<init_arg> to C<undef>, we make it impossible to set
this attribute when creating a new object.
-=head2 Weak References
+=head2 Weak references
Moose has built-in support for weak references. If you set the
C<weak_ref> option to a true value, then it will call
whenever the accessor is called. Second, it is also called if the
attribute is set via a lazy default or builder.
-=head2 Attribute Types
+=head2 Attribute types
Attributes can be restricted to only accept certain types:
Moose does absolutely nothing with this information other than store
it.
-=head2 The C<auto_deref> Option
+=head2 The C<auto_deref> option
If your attribute is an array reference or hash reference, the
C<auto_deref> option will make Moose dereference the value when it is
Of course, as with any list of "best practices", these are really just
opinions. Feel free to ignore us.
-=head2 "No Moose" and Immutabilize
+=head2 C<no Moose> and immutabilize
We recommend that you end your Moose class definitions by removing the
Moose sugar and making your class immutable.
The C<no Moose> bit is simply good code hygiene, and making classes
immutable speeds up a lot of things, most notably object construction.
-=head2 Always call SUPER::BUILDARGS
+=head2 Always call C<SUPER::BUILDARGS>
If you override the C<BUILDARGS> method in your class, make sure to
play nice and call C<SUPER::BUILDARGS> to handle cases you're not
list and hashref of named parameters correctly, and also checks for a
I<non-hashref> single argument.
-=head2 Don't Use the C<initializer> Feature
+=head2 Don't use the C<initializer> feature
Don't know what we're talking about? That's fine.
-=head2 Use C<builder> Instead of C<default> Most of the Time.
+=head2 Use C<builder> instead of C<default> most of the time
Builders can be inherited, they have explicit names, and they're just
plain cleaner.
going to be lazy, use I<lazy_build> to save yourself some typing and
standardize names.
-=head2 Consider Keeping Clearers and Predicates Private
+=head2 Consider keeping clearers and predicates private
Does everyone I<really> need to be able to clear an attribute?
Probably not. Don't expose this functionality outside your class
Predicates are less problematic, but there's no reason to make your
public API bigger than it has to be.
-=head2 Default to read-only, and Consider Keeping Writers Private
+=head2 Default to read-only, and consider keeping writers private
Making attributes mutable just means more complexity to account for in
your program. The alternative to mutable state is to encourage users
writer a separate private method. Narrower APIs are easy to maintain,
and mutable state is trouble.
-=head2 Think Twice Before Changing an Attribute's Type in a Subclass
+=head2 Think twice before changing an attribute's type in a subclass
Down this path lies great confusion. If the attribute is an object
itself, at least make sure that it has the same interface as the type
of object in the parent class.
-=head2 Use L<MooseX::AttributeHelpers> Instead of C<auto_deref>
+=head2 Use L<MooseX::AttributeHelpers> instead of C<auto_deref>
The C<auto_deref> feature is a bit troublesome. Directly exposing a
complex attribute is ugly. Instead, consider using
of functionality that need exposing. Then you can expose just the
functionality that you want.
-=head2 Namespace Your Types
+=head2 Namespace your types
Use some sort of namespacing convention for type names. We recommend
something like "MyApp.Type.Foo". I<Never> use "::" as the namespace
separator, since that overlaps with actual class names.
-=head2 Coercion Instead of Unions
+=head2 Coercion instead of unions
Consider using a type coercion instead of a type union. This was
covered at length in L<Moose::Manual::Types>.
-=head2 Define All Your Types in One Module
+=head2 Define all your types in one module
Define all your types and coercions in one module. This was also
covered in L<Moose::Manual::Types>.
=head1 NAME
-Moose::Manual::Concepts - Moose OO Concepts
+Moose::Manual::Concepts - Moose OO concepts
=head1 MOOSE CONCEPTS (VS "OLD SCHOOL" Perl)
$self->is_broken(1);
};
-=head2 Method Modifiers
+=head2 Method modifiers
A B<method modifier> is a hook that is called when a named method is
called. For example, you could say "before calling C<login()>, call
With old school Perl 5, this is the C<DESTROY()> method, but with
Moose it is the C<DEMOLISH()> method.
-=head2 Object Instance
+=head2 Object instance
An object instance is a specific noun in the class's "category". For
example, one specific Person or User. An instance is created by the
Moose, you should never need to know what your object instance
actually is. (ok, it's usually a blessed hashref with Moose too)
-=head2 Moose VS Old School Summary
+=head2 Moose vs old school summary
=over 4
debug( 'Made a new person - SSN = ', $self->ssn, );
}
-=head3 BUILD and Parent Classes
+=head3 BUILD and parent classes
The interaction between multiple C<BUILD> methods in an inheritance
hierarchy is different from normal Perl methods. B<You should never
=head1 NAME
-Moose::Manual::Delegation - Attribute Delegation
+Moose::Manual::Delegation - Attribute delegation
=head1 WHAT IS DELEGATION?
=head1 NAME
-Moose::Manual::MOP - The Moose (and Class::MOP) Meta API
+Moose::Manual::MOP - The Moose (and Class::MOP) meta API
=head1 INTRODUCTION
=head1 NAME
-Moose::Manual::MethodModifiers - Moose's Method Modifiers
+Moose::Manual::MethodModifiers - Moose's method modifiers
=head1 WHAT IS A METHOD MODIFIER?
=head1 NAME
-Moose::Manual::MooseX - Recommended Moose Extensions
+Moose::Manual::MooseX - Recommended Moose extensions
=head1 MooseX?
This document covers a few of the ones we like best.
-=head1 MooseX::AttributeHelpers
+=head1 L<MooseX::AttributeHelpers>
If you only look at one extension, it should be this one. It provides
the equivalent of delegation for all of Perl's native data types, such
Instead of directly exposing an array reference, we have three
well-named, easy to use methods.
-=head1 MooseX::StrictConstructor
+=head1 L<MooseX::StrictConstructor>
By default, Moose lets you pass any old junk into a class's
constructor. If you load L<MooseX::StrictConstructor>, your class will
runtime error. With plain old Moose, the "emali" attribute would be
silently ignored.
-=head1 MooseX::Params::Validate
+=head1 L<MooseX::Params::Validate>
We have high hopes for the future of L<MooseX::Method::Signatures> and
L<MooseX::Declare>. However, for now we recommend the decidedly more
...
}
-=head1 MooseX::Getopt
+=head1 L<MooseX::Getopt>
This is a role which adds a C<new_with_options> method to your
class. This is a constructor that takes the command line options and
foo@example> foo --input /path/to/input --output /path/to/output
-=head1 MooseX::Singleton
+=head1 L<MooseX::Singleton>
To be honest, using a singleton is often a hack, but it sure is a
handy hack. L<MooseX::Singleton> lets you have a Moose class that's a
of extensions that you might find useful, but we're not quite ready to
endorse just yet.
-=head2 MooseX::Declare
+=head2 L<MooseX::Declare>
Extends Perl with Moose-based keywords using C<Devel::Declare>. Very
cool, but still new and experimental.
method login (Str $password) { ... }
}
-=head2 MooseX::Types
+=head2 L<MooseX::Types>
This extension helps you build a type library for your application. It
also lets you pre-declare type names and use them as barewords.
in Moose's type registry, so multiple applications can use the same
bareword names, even if the type definitions differ.
-=head2 MooseX::Types::Structured
+=head2 L<MooseX::Types::Structured>
This extension builds on top of L<MooseX::Types> to let you declare
complex data structure types.
Of course, you could always use objects to represent these sorts of
things too.
-=head2 MooseX::ClassAttribute
+=head2 L<MooseX::ClassAttribute>
This extension provides class attributes for Moose classes. The
declared class attributes are introspectable just like regular Moose
class_has 'Cache' => ( ... );
-=head2 MooseX::Daemonize
+=head2 L<MooseX::Daemonize>
This is a role that provides a number of methods useful for creating a
daemon, including methods for starting and stopping, managing a PID
file, and signal handling.
-=head2 MooseX::Role::Parameterized
+=head2 L<MooseX::Role::Parameterized>
If you find yourself wanting a role that customizes itself for each
consumer, this is the tool for you. With this module, you can create a
role that accepts parameters and generates attributes, methods, etc on
a customized basis for each consumer.
-=head2 MooseX::POE
+=head2 L<MooseX::POE>
This is a small wrapper that ties together a Moose class with
C<POE::Session>, and gives you an C<event> sugar function to declare
event handlers.
-=head2 MooseX::FollowPBP
+=head2 L<MooseX::FollowPBP>
Automatically names all accessors I<Perl Best Practices>-style,
"get_size" and "set_size".
-=head2 MooseX::SemiAffordanceAccessor
+=head2 L<MooseX::SemiAffordanceAccessor>
Automatically names all accessors with an explicit set and implicit
get, "size" and "set_size".
=head1 NAME
-Moose::Manual::Roles - Roles, an Alternative to Deep Hierarchies and Base Classes
+Moose::Manual::Roles - Roles, an alternative to deep hierarchies and base classes
=head1 WHAT IS A ROLE?
=head1 NAME
-Moose::Manual::Types - Moose's Type System
+Moose::Manual::Types - Moose's type system
=head1 TYPES IN PERL?
Note that the sugar functions for working with types are all exported
by L<Moose::Util::TypeConstraints>.
-=head2 Creating a New Type (That Isn't a Subtype)
+=head2 Creating a new type (that isn't a subtype)
You can also create new top-level types:
This code example will do the right thing, and the newly created
object will have C<[ 42 ]> as its C<sizes> attribute.
-=head2 Deep Coercion
+=head2 Deep coercion
Deep coercion is the coercion of type parameters for parameterized
types. Let's take these types as an example:
projects / gitmo/Moose.git / commitdiff