-=pod
+
=head1 NAME
-Moose::Manual::Concepts - Moose OO Concepts
+Moose::Manual::Concepts - Moose OO concepts
=head1 MOOSE CONCEPTS (VS "OLD SCHOOL" Perl)
In the past, you may not have thought too much about the difference
between packages and classes, attributes and methods, constructors and
-methods, etc. Part of what the MOP provides is well-defined
-introspection features for each of those things, and in turn Moose
-provides I<distinct> sugar for each of them. Moose also introduces
-concepts that are uncommon (or entirely new) like roles, method
-modifiers, and declarative delegation.
+methods, etc. With Moose, these are all conceptually separate things,
+even though under the hood they're implemented with plain old Perl.
+
+Our meta-object protocol (aka MOP) provides well-defined introspection
+features for each of those concepts, and Moose in turn provides
+distinct sugar for each of them. Moose also introduces additional
+concepts such as roles, method modifiers, and declarative delegation.
Knowing what these concepts mean in Moose-speak, and how they used to
be done in old school Perl 5 OO is a good way to start learning to use
=head2 Class
-When you say "use Moose" in a package, you are defining your package
-as a class. At its simplest, a class will consist simply of attributes
+When you say "use Moose" in a package, you are making your package a
+class. At its simplest, a class will consist simply of attributes
and/or methods. It can also include roles, method modifiers, and more.
A class I<has> zero or more B<attributes>.
apply to its own methods or methods that are inherited from its
ancestors.
-A class I<does> zero or more B<roles>.
+A class I<does> (and I<consumes>) zero or more B<roles>.
A class I<has> a B<constructor> and a B<destructor>. These are
provided for you "for free" by Moose.
=head2 Attribute
An attribute is a property of the class that defines it. It I<always>
-has a name, and it I<may have> a number of other defining
-characteristics.
+has a name, and it I<may have> a number of other properties.
-These characteristics may include a read/write flag, a B<type>,
-accessor method names, B<delegations>, a default value, and more.
+These properties can include a read/write flag, a B<type>, accessor
+method names, B<delegations>, a default value, and more.
Attributes I<are not> methods, but defining them causes various
accessor methods to be created. At a minimum, a normal attribute will
-always have a reader accessor method. Many attributes have things like
-a writer method, clearer method, and predicate method ("has it been
-set?").
+always have a reader accessor method. Many attributes also other
+methods such as a writer method, clearer method, and predicate method
+("has it been set?").
-An attribute may also define B<delegation>s, which will create
-additional methods based on the delegation specification.
+An attribute may also define B<delegations>, which will create
+additional methods based on the delegation mapping.
By default, Moose stores attributes in the object instance, which is a
-hashref, I<but this is invisible to the author of a Moose-base class>!
-It is best to think of Moose attributes as "properties" of the
-I<opaque> B<object instance>. These properties are accessed through
-well-defined accessor methods.
+hashref, I<but this is invisible to the author of a Moose-based
+class>! It is best to think of Moose attributes as "properties" of
+the I<opaque> B<object instance>. These properties are accessed
+through well-defined accessor methods.
-An attribute is usually analogous to a specific feature of something in
-the class's category. For example, People have first and last
-names. Users have passwords and last login datetimes.
+An attribute is something that the class's members have. For example,
+People have first and last names. Users have passwords and last login
+datetimes.
has 'first_name' => (
is => 'rw',
=head2 Method
-A method is very straightforward. Any subroutine you define in your
+A B<method> is very straightforward. Any subroutine you define in your
class is a method.
-Methods correspond to verbs, and are what your objects can do. For
+B<Methods> correspond to verbs, and are what your objects can do. For
example, a User can login.
sub login { ... }
=head2 Roles
-A role is something that a class I<does>. For example, a Machine class
-might do the Breakable role, and so could a Bone class. A role is
-used to define some concept that cuts across multiple unrelated
-classes, like "breakability", or "has a color".
+A role is something that a class I<does>. We also say that classes
+I<consume> roles. For example, a Machine class might do the Breakable
+role, and so could a Bone class. A role is used to define some concept
+that cuts across multiple unrelated classes, like "breakability", or
+"has a color".
A role I<has> zero or more B<attributes>.
A role I<has> zero or more B<required methods>.
-A required method is not implemented by the role. Instead, a required
-method says "to use this Role you must implement this method".
+A required method is not implemented by the role. Required methods say
+"to use this Role you must implement this method".
+
+A role I<has> zero or more B<excluded roles>.
+
+An excluded role is a role that the role doing the excluding says it
+cannot be combined with.
Roles are I<composed> into classes (or other roles). When a role is
composed into a class, its attributes and methods are "flattened" into
$self->is_broken(1);
};
-=head2 Method Modifiers
+=head2 Method modifiers
-A method modifier is a way of defining an action to be taken when a
-named method is called. Think of it as a hook on the named method. For
-example, you could say "before calling C<login()>, call this modifier
-first". Modifiers come in different flavors like "before", "after",
-"around", and "augment", and you can apply more than one modifier to
-a single method.
+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
+this modifier first". Modifiers come in different flavors like
+"before", "after", "around", and "augment", and you can apply more
+than one modifier to a single method.
Method modifiers are often used as an alternative to overriding a
method in a parent class. They are also used in roles as a way of
Moose also comes with a (miniature) type system. This allows you to
define types for attributes. Moose has a set of built-in types based
-on what Perl provides, such as "Str", "Num", "Bool", "HashRef", etc.
+on what Perl provides, such as C<Str>, C<Num>, C<Bool>, C<HashRef>, etc.
In addition, every class name in your application can also be used as
-a type name. We saw an example using "DateTime" earlier.
+a type name. We saw an example using C<DateTime> earlier.
Finally, you can define your own types, either as subtypes or entirely
new types, with their own constraints. For example, you could define a
-type "PosInt", a subtype of "Int" which only allows positive numbers.
+type C<PosInt>, a subtype of C<Int> which only allows positive numbers.
=head2 Delegation
Moose attributes provide declarative syntax for defining
-delegations. A delegation is a method which delegates the real work to
-some attribute of the class.
-
-You saw this in the User example, where we defined a delegation for
-the C<date_of_last_login()> method. Under the hood, this simple calls
-C<date()> on the User object's C<last_login> attribute.
+delegations. A delegation is a method which calls some method on an
+attribute to do its real work.
=head2 Constructor
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
In old school Perl 5, this is often a blessed hash reference. With
Moose, you should never need to know what your object instance
-actually is. (ok, it's usually a blessed hashref with Moose too)
+actually is. (Okay, it's usually a blessed hashref with Moose, too.)
-=head2 Moose VS Old School Summary
+=head2 Moose vs old school summary
=over 4
One of the great things about Moose is that if you dig down and find
that it does something the "wrong way", you can change it by extending
a metaclass. For example, you can have arrayref based objects, you can
-make your constructors strict (no unknown params allowed!), you can
+make your constructors strict (no unknown parameters allowed!), you can
define a naming scheme for attribute accessors, you can make a class a
Singleton, and much, much more.
5 OO code, check out L<Moose::Unsweetened>. This might be helpful for
quickly wrapping your brain around some aspects of "the Moose way".
-Obviously, the first thing to read is the L<Moose::Manual>
+Obviously, the next thing to read is the rest of the L<Moose::Manual>.
After that we recommend that you start with the L<Moose::Cookbook>. If
you work your way through all the recipes under the basics section,
=head1 COPYRIGHT AND LICENSE
-Copyright 2008 by Infinity Interactive, Inc.
+Copyright 2008-2009 by Infinity Interactive, Inc.
L<http://www.iinteractive.com>
it under the same terms as Perl itself.
=cut
-
projects / gitmo/Moose.git / blobdiff