Yes! Many sites with household names are using Moose to build
high-traffic services. Countless others are using Moose in production.
-See L<http://www.iinteractive.com/moose/about.html#organizations> for
+See L<http://moose.iinteractive.com/about.html#organizations> for
a partial list.
As of this writing, Moose is a dependency of several hundred CPAN
-modules. L<http://cpants.perl.org/dist/used_by/Moose>
+modules. L<https://metacpan.org/requires/module/Moose>
=head3 Is Moose's API stable?
NOTE: This B<cannot> be set globally in Moose, as that would break
other classes which are built with Moose. You can still save on typing
-by defining a new L<MyApp::Moose> that exports Moose's sugar and then
+by defining a new C<MyApp::Moose> that exports Moose's sugar and then
turns on L<MooseX::FollowPBP>. See
L<Moose::Cookbook::Extending::Recipe4>.
=head3 My coercions stopped working with recent Moose, why did you break it?
-Moose 0.76 fixed a case where Coercions were being applied even if the original constraint passed. This has caused some edge cases to fail where people were doing something like
+Moose 0.76 fixed a case where coercions were being applied even if the original
+constraint passed. This has caused some edge cases to fail where people were
+doing something like
- subtype Address => as 'Str';
- coerce Address => from Str => via { get_address($_) };
+ subtype 'Address', as 'Str';
+ coerce 'Address', from 'Str', via { get_address($_) };
-Which is not what they intended. The Type Constraint C<Address> is too loose in this case, it is saying that all Strings are Addresses, which is obviously not the case. The solution is to provide a where clause that properly restricts the Type Constraint.
+This is not what they intended, because the type constraint C<Address> is too
+loose in this case. It is saying that all strings are Addresses, which is
+obviously not the case. The solution is to provide a C<where> clause that
+properly restricts the type constraint:
- subtype Address => as Str => where { looks_like_address($_) };
+ subtype 'Address', as 'Str', where { looks_like_address($_) };
-This will allow the coercion to apply only to strings that fail to look like an Address.
+This will allow the coercion to apply only to strings that fail to look like an
+Address.
=head2 Roles
=item *
Using a combination of lazy and default in your attributes to defer
-initialization (see the Binary Tree example in the cookbook for a good
-example of lazy/default usage L<Moose::Cookbook::Basics::Recipe3>)
+initialization (see the Binary Tree example in the cookbook for a good example
+of lazy/default usage
+L<Moose::Cookbook::Basics::BinaryTree_AttributeFeatures>)
=item *
classes. Or, at the very least, you should reduce the amount of
functionality in your role so that it does not require initialization.
-=head3 What are Traits, and how are they different from Roles?
+=head3 What are traits, and how are they different from 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
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.
+the same thing. The original paper called them traits, but Perl 6
+will call them roles.
+
+=head3 Can an attribute-generated method (e.g. an accessor) satisfy requires?
+
+Yes, just be sure to consume the role I<after> declaring your
+attribute. L<Moose::Manual::Roles/Required Attributes> provides
+an example:
+
+ package Breakable;
+ use Moose::Role;
+ requires 'stress';
+
+ package Car;
+ use Moose;
+ has 'stress' => ( is => 'rw', isa => 'Int' );
+ with 'Breakable';
+
+If you mistakenly consume the C<Breakable> role before declaring your
+C<stress> attribute, you would see an error like this:
+
+ 'Breakable' requires the method 'stress' to be implemented by 'Car' at...
=head2 Moose and Subroutine Attributes
=head3 Why don't subroutine attributes I inherited from a superclass work?
-Currently when you subclass a module, this is done at runtime with the
-C<extends> keyword but attributes are checked at compile time by
+Currently when subclassing a module is done at runtime with the
+C<extends> keyword, but attributes are checked at compile time by
Perl. To make attributes work, you must place C<extends> in a C<BEGIN>
-block so that the attribute handlers will be available at compile time
+block so that the attribute handlers will be available at compile time,
like this:
BEGIN { extends qw/Foo/ }