=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?
=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
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;
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
=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?
projects / gitmo/Moose.git / blobdiff