X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FMoose%2FManual%2FConstruction.pod;h=be2d3e2b1a774ea35165bdd721bdaaadfd4be397;hb=c24269b37a781e0358c3682e8717cfd539269550;hp=1a17e64758783ded01f6cf060c6b4f002813af11;hpb=0c39debe42b82fda7f19f3053903650ac7920a65;p=gitmo%2FMoose.git

diff --git a/lib/Moose/Manual/Construction.pod b/lib/Moose/Manual/Construction.pod
index 1a17e64..be2d3e2 100644
--- a/lib/Moose/Manual/Construction.pod
+++ b/lib/Moose/Manual/Construction.pod
@@ -6,7 +6,7 @@ Moose::Manual::Construction - Object construction (and destruction) with Moose
 
 =head1 WHERE'S THE CONSTRUCTOR?
 
-B<You do not need to define a C<new()> method for your classes!>
+B<Do not define a C<new()> method for your classes!>
 
 When you C<use Moose> in your class, you will become a subclass of
 L<Moose::Object>, which provides a C<new> method for you. If you
@@ -50,28 +50,29 @@ Without a C<BUILDARGS> method, Moose will complain, because it expects
 a hash or hash reference. We can use the C<BUILDARGS> method to
 accommodate this calling style:
 
-  sub BUILDARGS {
+  around BUILDARGS => sub {
+      my $orig = shift;
       my $class = shift;
 
       if ( @_ == 1 && ! ref $_[0] ) {
-          return { ssn => $_[0] };
+          return $class->$orig(ssn => $_[0]);
       }
       else {
-          return $class->SUPER::BUILDARGS(@_);
+          return $class->$orig(@_);
       }
-  }
+  };
 
-Note the call to C<SUPER::BUILDARGS>. This will call the default
+Note the call to C<< $class->$orig >>. This will call the default
 C<BUILDARGS> in L<Moose::Object>. This method handles distinguishing
 between a hash reference and a plain hash for you.
 
 =head2 BUILD
 
 The C<BUILD> method is called I<after> an object is created. There are
-ways to use a C<BUILD> method. One of the most common is to check that
-the object state is valid. While we can validate individual attributes
-through the use of types, we can't validate the state of a whole
-object that way.
+several ways to use a C<BUILD> method. One of the most common is to
+check that the object state is valid. While we can validate individual
+attributes through the use of types, we can't validate the state of a
+whole object that way.
 
   sub BUILD {
       my $self = shift;
@@ -91,7 +92,14 @@ object creation.
       debug( 'Made a new person - SSN = ', $self->ssn, );
   }
 
-=head3 BUILD and Parent Classes
+Note that while it is not shown here, the C<BUILD> method receives  
+not only the created object, but also a hashref of the original 
+arguments passed to new (or the results of your C<BUILDARGS>, 
+if you have overridden the default C<BUILDARGS>.)  This can be 
+useful if you need to venture beyond what the default 
+initialization behavior and coercions can accomplish.
+
+=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
@@ -104,7 +112,8 @@ normal order of method inheritance.
 
 The theory behind this is that C<BUILD> methods can only be used for
 increasing specialization of a class's constraints, so it makes sense
-to call the least specific first (also, this is how Perl 6 does it).
+to call the least specific C<BUILD> method first. Also, this is how
+Perl 6 does it.
 
 =head1 OBJECT DESTRUCTION