X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FMoose%2FCookbook%2FFAQ.pod;h=74f06d1bd2e0541c3fd23fe3e8fad36606871505;hb=bb6c833559f9e6ac403628d8ec4d09af2a0477e1;hp=5fd9f782502642a1a7157f5e132f6332f22d2581;hpb=e48bf54578e3aa18b4d14add6f28d079e90cff61;p=gitmo%2FMoose.git

diff --git a/lib/Moose/Cookbook/FAQ.pod b/lib/Moose/Cookbook/FAQ.pod
index 5fd9f78..74f06d1 100644
--- a/lib/Moose/Cookbook/FAQ.pod
+++ b/lib/Moose/Cookbook/FAQ.pod
@@ -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,6 +282,21 @@ 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>