clarify a bit

[gitmo/Moose.git] / lib / Moose / Cookbook / Basics / Recipe4.pod

diff --git a/lib/Moose/Cookbook/Basics/Recipe4.pod b/lib/Moose/Cookbook/Basics/Recipe4.pod
index 7570e9a..d9d5dfd 100644 (file)
--- a/lib/Moose/Cookbook/Basics/Recipe4.pod
+++ b/lib/Moose/Cookbook/Basics/Recipe4.pod
@@ -148,10 +148,10 @@ simplifies the code. We don't really need a class for these types, as
 they're just strings, but we do want to ensure that they're valid.
 
 The type constraints we created are reusable. Type constraints are
-stored by name in a global registry. This means that we can refer to
+stored by name in a global registry, which means that we can refer to
 them in other classes. Because the registry is global, we do recommend
-that you use some sort of pseudo-namespacing in real applications,
-like C<MyApp.Type.USState>.
+that you use some sort of namespacing in real applications,
+like C<MyApp::Type::USState> (just as you would do with class names).
 
 These two subtypes allow us to define a simple C<Address> class.
 
@@ -252,7 +252,7 @@ arguments to C<super>. Instead, Moose simply passes the same
 parameters that were passed to the method.
 
 A more detailed example of usage can be found in
-F<t/000_recipes/moose_cookbook_basics_recipe4.t>.
+F<t/recipes/moose_cookbook_basics_recipe4.t>.
 
 =head1 CONCLUSION
 
@@ -284,10 +284,9 @@ container type, and instead you will have a new type named
 
 =item (3)
 
-The C<BUILD> method is actually called by C<< Moose::Object->BUILDALL
->>, which is called by C<< Moose::Object->new >>. The C<BUILDALL>
-method climbs the object inheritance graph and calls any C<BUILD>
-methods it finds in the correct order.
+The C<BUILD> method is actually called by C<< Moose::Object->new >>. It climbs
+the object inheritance graph and calls any C<BUILD> methods it finds in the
+correct order.
 
 =back