Revised meta recipe 5
[gitmo/Moose.git] / lib / Moose / Cookbook / FAQ.pod
index 5fd9f78..6199a26 100644 (file)
@@ -16,7 +16,7 @@ production using Moose, they have been running without
 issue now for well over a year. 
 
 At C<$work> we are re-writing our core offering to use Moose, 
-so it's continued development is assured. 
+so its continued development is assured. 
 
 Several other people on #moose either have apps in production 
 which use Moose, or are in the process of deploying sites 
@@ -84,8 +84,8 @@ pairs or a hash reference. You can override it to take positional args,
 or any other format
 
 To change the handling of individual parameters, there are I<coercions>
-(See the L<Moose::Cookbook::Recipe5> for a complete example and
-explaination of coercions). With coercions it is possible to morph
+(See the L<Moose::Cookbook::Basics::Recipe5> for a complete example and
+explanation of coercions). With coercions it is possible to morph
 argument values into the correct expected types. This approach is the
 most flexible and robust, but does have a slightly higher learning
 curve.
@@ -97,7 +97,7 @@ delegation.  Moose makes this easy using the C<handles> keyword,
 coercions, and C<lazy_build>, so subclassing is often not the
 ideal route.
 
-That said, the default Moose constructors is inherited from
+That said, the default Moose constructor is inherited from
 L<Moose::Object>. When inheriting from a non-Moose class, the
 inheritance chain to L<Moose::Object> is broken. The simplest way
 to fix this is to simply explicitly inherit from L<Moose::Object>
@@ -172,7 +172,7 @@ L<Moose::Policy::FollowPBP>. This will allow you to write:
       is  => 'rw',
   );
 
-And have Moose create seperate C<get_bar> and C<set_bar> methods
+And have Moose create separate C<get_bar> and C<set_bar> methods
 instead of a single C<bar> method.
 
 NOTE: This B<cannot> be set globally in Moose, as that would break 
@@ -204,7 +204,7 @@ coerce the value into a C<DateTime> object using the code in found
 in the C<via> block. 
 
 For a more comprehensive example of using coercions, see the
-L<Moose::Cookbook::Recipe5>.
+L<Moose::Cookbook::Basics::Recipe5>.
 
 If you need to deflate your attribute, the current best practice is to 
 add an C<around> modifier to your accessor. Here is some example code:
@@ -282,13 +282,28 @@ release.
 See L<Moose::Cookbook::WTF> and specifically the B<How come BUILD 
 is not called for my composed roles?> question in the B<Roles> section.
 
+=head3 What are Traits, and how are they different to Roles?
+
+In Moose, a trait is almost exactly the same thing as a role, except
+that traits typically register themselves, which allows you to refer
+to them by a short name ("Big" vs "MyApp::Role::Big").
+
+In Moose-speak, a I<Role> is usually composed into a I<class> at
+compile time, whereas a I<Trait> is usually composed into an instance
+of a class at runtime to add or modify the behavior of B<just that
+instance>.
+
+Outside the context of Moose, traits and roles generally mean exactly the
+same thing. The original paper called them Traits, however Perl 6 will call
+them Roles.
+
 =head1 AUTHOR
 
 Stevan Little E<lt>stevan@iinteractive.comE<gt>
 
 =head1 COPYRIGHT AND LICENSE
 
-Copyright 2006-2008 by Infinity Interactive, Inc.
+Copyright 2006-2009 by Infinity Interactive, Inc.
 
 L<http://www.iinteractive.com>