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=e9aeb6f190e670c59461ccda531ccc87bb15f92f;hpb=ce21ecc578e3154f99399f49bde10e93bf390afa;p=gitmo%2FMoose.git

diff --git a/lib/Moose/Cookbook/FAQ.pod b/lib/Moose/Cookbook/FAQ.pod
index e9aeb6f..74f06d1 100644
--- a/lib/Moose/Cookbook/FAQ.pod
+++ b/lib/Moose/Cookbook/FAQ.pod
@@ -84,21 +84,29 @@ 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.
 
 =head3 How do I make non-Moose constructors work with Moose? 
 
-Moose provides its own constructor, but it does it by making all 
-Moose-based classes inherit 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> yourself. However, this does not 
-always fix the issue of a constructor. Here is a basic example of 
-how this can be worked around:
+Usually the correct approach to subclassing a non Moose class is
+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 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>
+yourself.
+
+However, this does not always fix the issue of actually calling the Moose
+constructor. Fortunately L<Class::MOP::Class/new_object>, the low level
+constructor, accepts the special C<__INSTANCE__> parameter, allowing you to
+instantiate your Moose attributes:
 
   package My::HTML::Template;
   use Moose;
@@ -114,13 +122,17 @@ how this can be worked around:
       return $class->meta->new_object(
           # pass in the constructed object
           # using the special key __INSTANCE__
-          __INSTANCE__ => $obj, @_
+          __INSTANCE__ => $obj,
+          @_, # pass in the normal args
       );
   }
 
 Of course, this only works if both your Moose class and the 
 inherited non-Moose class use the same instance type (typically 
-HASH refs). 
+HASH refs).
+
+Note that this doesn't call C<BUILDALL> automatically, you must do that
+yourself.
 
 Other techniques can be used as well, such as creating the object 
 using C<Moose::Object::new>, but calling the inherited non-Moose 
@@ -160,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 
@@ -192,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:
@@ -270,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>