exception.
You can make a class mutable again simply by calling C<<
-$metaclass->make_mutable >>. Once you're done changing it, you can
-restore immutability by calling C<< $metaclass->make_immutable >>.
+$meta->make_mutable >>. Once you're done changing it, you can
+restore immutability by calling C<< $meta->make_immutable >>.
-However, the most common use for this part of of the meta API is as
+However, the most common use for this part of the meta API is as
part of Moose extensions. These extensions should assume that they are
being run before you make a class immutable.
package User;
use Moose;
- use MooseX::Params::Validate qw( validatep );
+ use MooseX::Params::Validate;
sub login {
my $self = shift;
This extension helps you build a type library for your application. It
also lets you predeclare type names and use them as barewords.
- use MooseX::Types -declare => ['PosInt'];
+ use MooseX::Types -declare => ['PositiveInt'];
use MooseX::Types::Moose 'Int';
subtype PositiveInt
If you find yourself wanting a role that customizes itself for each
consumer, this is the tool for you. With this module, you can create a
-role that accepts parameters and generates attributes, methods, etc on
+role that accepts parameters and generates attributes, methods, etc. on
a customized basis for each consumer.
=head2 L<MooseX::POE>
The C<Maybe[`a]> type deserves a special mention. Used by itself, it
doesn't really mean anything (and is equivalent to C<Item>). When it
is parameterized, it means that the value is either C<undef> or the
-parameterized type. So C<Maybe[Int]> means an integer or C<undef>
+parameterized type. So C<Maybe[Int]> means an integer or C<undef>.
For more details on the type hierarchy, see
L<Moose::Util::TypeConstraints>.
L<Moose::Util::TypeConstraints>:
class_type('MyApp::User')
- unless find_type_constraint('MyApp::User') || ;
+ unless find_type_constraint('MyApp::User');
This sort of "find or create" logic is simple to write, and will let
you work around load order issues.