Moose FAQ: Expand "Can I turn off type constraint checking?"
[gitmo/Moose.git] / lib / Moose / Manual / Concepts.pod
index 9820b05..e603e48 100644 (file)
@@ -1,15 +1,17 @@
+package Moose::Manual::Concepts;
 
+# ABSTRACT: Moose OO concepts
 
-=head1 NAME
+__END__
 
-Moose::Manual::Concepts - Moose OO concepts
+=pod
 
 =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. With Moose, these are all conceptually separate things,
-even though under the hood they're implemented with plain old Perl.
+methods, etc. With Moose, these are all conceptually separate,
+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
@@ -67,8 +69,8 @@ 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 also other
-methods such as a writer method, clearer method, and predicate method
+have a reader accessor method. Many attributes have other
+methods, such as a writer method, a clearer method, or a predicate method
 ("has it been set?").
 
 An attribute may also define B<delegations>, which will create
@@ -99,7 +101,7 @@ example, a User can login.
 
   sub login { ... }
 
-=head2 Roles
+=head2 Role
 
 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
@@ -115,8 +117,8 @@ A role I<has> zero or more B<method modifiers>.
 
 A role I<has> zero or more B<required methods>.
 
-A required method is not implemented by the role. Required methods say
-"to use this Role you must implement this method".
+A required method is not implemented by the role. Required methods are a way
+for the role to declare "to use this role you must implement this method".
 
 A role I<has> zero or more B<excluded roles>.
 
@@ -135,14 +137,14 @@ Role are somewhat like mixins or interfaces in other OO languages.
 
   use Moose::Role;
 
-  has is_broken => (
+  requires 'break';
+
+  has 'is_broken' => (
       is  => 'rw',
       isa => 'Bool',
   );
 
-  requires 'break';
-
-  before 'break' => {
+  after 'break' => sub {
       my $self = shift;
 
       $self->is_broken(1);
@@ -172,22 +174,22 @@ that gets called before or after (or around, etc.) some named method.
 
 =head2 Type
 
-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.
+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 the types
+Perl provides in its core, 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.
 
-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.
+Finally, you can define your own types with their own constraints. For
+example, you could define a C<PosInt> type, 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 calls some method on an
-attribute to do its real work.
+Moose attributes provide declarative syntax for defining delegations. A
+delegation is a method which in turn calls some method on an attribute to do
+its real work.
 
 =head2 Constructor
 
@@ -223,7 +225,7 @@ person has a first and last name.
 
 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
 
@@ -265,7 +267,7 @@ probably never saw this before (at least in Perl 5).
 Hand-written parameter checking in your C<new()> method and accessors.
 
 With Moose, you define types declaratively, and then use them by name
-in your attributes.
+with your attributes.
 
 =item * Delegation
 
@@ -305,14 +307,14 @@ like object construction and so on.
 
 =head1 META WHAT?
 
-A metaclass is a class that describes classes. With Moose, every class
-you define gets a C<meta()> method. It returns a L<Moose::Meta::Class>
-object, which has an introspection API that can tell you about the
-class it represents.
+A metaclass is a class that describes classes. With Moose, every class you
+define gets a C<meta()> method. The C<meta()> method returns a
+L<Moose::Meta::Class> object, which has an introspection API that can tell you
+about the class it represents.
 
   my $meta = User->meta();
 
-  for my $attribute ( $meta->compute_all_applicable_attributes ) {
+  for my $attribute ( $meta->get_all_attributes ) {
       print $attribute->name(), "\n";
 
       if ( $attribute->has_type_constraint ) {
@@ -320,7 +322,7 @@ class it represents.
       }
   }
 
-  for my $method ( $meta->compute_all_applicable_methods ) {
+  for my $method ( $meta->get_all_methods ) {
       print $method->name, "\n";
   }
 
@@ -334,7 +336,7 @@ L<Moose::Meta::TypeConstraint>, L<Moose::Meta::Instance>, and so on.
 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.
 
@@ -355,11 +357,13 @@ extensions.
 
 So you're sold on Moose. Time to learn how to really use it.
 
-If you want to see how Moose would translate directly old school Perl
-5 OO code, check out L<Moose::Unsweetened>. This might be helpful for
-quickly wrapping your brain around some aspects of "the Moose way".
+If you want to see how Moose would translate directly into old school
+Perl 5 OO code, check out L<Moose::Manual::Unsweetened>. This might be
+helpful for quickly wrapping your brain around some aspects of "the
+Moose way".
 
-Obviously, the next thing to read is the rest of the L<Moose::Manual>.
+Or you can skip that and jump straight to L<Moose::Manual::Classes>
+and 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,
@@ -368,19 +372,6 @@ basic OO features.
 
 After that, check out the Role recipes. If you're really curious, go
 on and read the Meta and Extending recipes, but those are mostly there
-for people who want to be Moose wizards and change how Moose works.
-
-=head1 AUTHOR
-
-Dave Rolsky E<lt>autarch@urth.orgE<gt>
-
-=head1 COPYRIGHT AND LICENSE
-
-Copyright 2008-2009 by Infinity Interactive, Inc.
-
-L<http://www.iinteractive.com>
-
-This library is free software; you can redistribute it and/or modify
-it under the same terms as Perl itself.
+for people who want to be Moose wizards and extend Moose itself.
 
 =cut