X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FMoose%2FCookbook%2FFAQ.pod;h=6ff53af826d725a7cab529de27a7d25bbfc89d8c;hb=37a9448b781fec00a31fed31130b3531c4029a30;hp=94378814003476a3cd8557c384bfd6a5ad2beec3;hpb=d03bd989b97597428b460d7f9a021e2931893fa0;p=gitmo%2FMoose.git

diff --git a/lib/Moose/Cookbook/FAQ.pod b/lib/Moose/Cookbook/FAQ.pod
index 9437881..6ff53af 100644
--- a/lib/Moose/Cookbook/FAQ.pod
+++ b/lib/Moose/Cookbook/FAQ.pod
@@ -11,24 +11,24 @@ Moose::Cookbook::FAQ - Frequently asked questions about Moose
 
 =head3 Is Moose "production ready"?
 
-Yes. I have several medium-to-large-ish web applications in
-production using Moose, they have been running without
-issue now for well over a year.
+Yes! Many sites with household names are using Moose to build
+high-traffic services. Countless others are using Moose in
+production.
 
-At C<$work> we are re-writing our core offering to use Moose,
-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
-which use Moose.
+As of this writing, Moose is a dependency of several hundred CPAN
+modules. L<http://cpants.perl.org/dist/used_by/Moose>
 
 =head3 Is Moose's API stable?
 
-Yes and No. The external API, the one 90% of users will interact
-with, is B<very stable> and any changes B<will be 100% backwards
-compatible>. The introspection API is I<mostly> stable; I still
-reserve the right to tweak that if needed, but I will do my
-absolute best to maintain backwards compatibility here as well.
+Yes. The sugary API, the one 95% of users will interact with, is
+B<very stable>. Any changes will be B<100% backwards compatible>.
+
+The meta API is less set in stone. We reserve the right to tweak
+parts of it to improve efficiency or consistency. This will not be
+done lightly. We do perform deprecation cycles. We I<really>
+do not like making ourselves look bad by breaking your code.
+Submitting test cases is the best way to ensure that your code is not
+inadvertantly broken by refactoring.
 
 =head3 I heard Moose is slow, is this true?
 
@@ -57,7 +57,8 @@ conversion to XS.
 
 =head3 When will Moose 1.0 be ready?
 
-It is right now, I declared 0.18 to be "ready to use".
+Moose is ready now! Stevan Little declared 0.18, released in March 2007,
+to be "ready to use".
 
 =head2 Constructors
 
@@ -104,9 +105,13 @@ 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:
+constructor. Fortunately, the modules L<MooseX::NonMoose> and
+L<MooseX::Alien> aim to make subclassing non-Moose classes easier.
+
+If neither extension fills your specific needs, you can use
+L<Class::MOP::Class/new_object>. This low-level constructor accepts the
+special C<__INSTANCE__> parameter, allowing you to instantiate your Moose
+attributes:
 
   package My::HTML::Template;
   use Moose;
@@ -138,14 +143,10 @@ Other techniques can be used as well, such as creating the object
 using C<Moose::Object::new>, but calling the inherited non-Moose
 class's initialization methods (if available).
 
-It is also entirely possible to just rely on HASH autovivification
-to create the slots needed for Moose based attributes, although this
-does restrict use of construction time attribute features somewhat.
-
-In short, there are several ways to go about this, it is best to
-evaluate each case based on the class you wish to extend, and the
-features you wish to employ. As always, both IRC and the mailing
-list are great ways to get help finding the best approach.
+In short, there are several ways to extend non-Moose classes. It is
+best to evaluate each case based on the class you wish to extend,
+and the features you wish to employ. As always, both IRC and the
+mailing list are great ways to get help finding the best approach.
 
 =head2 Accessors
 
@@ -233,8 +234,17 @@ explain it on #moose or the mailing list.
 =head3 How can I affect the values in C<@_> using C<before>?
 
 You can't, actually: C<before> only runs before the main method,
-and it cannot easily affect the method's execution. What you want is
-an C<around> method.
+and it cannot easily affect the method's execution.
+
+You similarly can't use C<after> to affect the return value of a
+method.
+
+We limit C<before> and C<after> because this lets you write more
+concise code. You do not have to worry about passing C<@_> to the
+original method, or forwarding its response (being careful to preserve
+context).
+
+The C<around> method modifier has neither of these limitations.
 
 =head3 Can I use C<before> to stop execution of a method?