Moose::Cookbook::Meta:UseriContributed Perl DMoose::Cookbook::Meta::Recipe3(3)NAMEMoose::Cookbook::Meta::Recipe3 - Labels implemented via attribute
traits
VERSION
version 2.0402
SYNOPSIS
package MyApp::Meta::Attribute::Trait::Labeled;
use Moose::Role;
has label => (
is => 'rw',
isa => 'Str',
predicate => 'has_label',
);
package Moose::Meta::Attribute::Custom::Trait::Labeled;
sub register_implementation {'MyApp::Meta::Attribute::Trait::Labeled'}
package MyApp::Website;
use Moose;
has url => (
traits => [qw/Labeled/],
is => 'rw',
isa => 'Str',
label => "The site's URL",
);
has name => (
is => 'rw',
isa => 'Str',
);
sub dump {
my $self = shift;
my $meta = $self->meta;
my $dump = '';
for my $attribute ( map { $meta->get_attribute($_) }
sort $meta->get_attribute_list ) {
if ( $attribute->does('MyApp::Meta::Attribute::Trait::Labeled')
&& $attribute->has_label ) {
$dump .= $attribute->label;
}
else {
$dump .= $attribute->name;
}
my $reader = $attribute->get_read_method;
$dump .= ": " . $self->$reader . "\n";
}
return $dump;
}
package main;
my $app = MyApp::Website->new( url => "http://google.com", name => "Google" );
BUT FIRST
This recipe is a variation on Moose::Cookbook::Meta::Recipe2. Please
read that recipe first.
MOTIVATION
In Moose::Cookbook::Meta::Recipe2, we created an attribute metaclass
which lets you provide a label for attributes.
Using a metaclass works fine until you realize you want to add a label
and an expiration, or some other combination of new behaviors. You
could create yet another metaclass which subclasses those two, but that
makes a mess, especially if you want to mix and match behaviors across
many attributes.
Fortunately, Moose provides a much saner alternative, which is to
encapsulate each extension as a role, not a class. We can make a role
which adds a label to an attribute, and could make another to implement
expiration.
TRAITS
Roles that apply to metaclasses have a special name: traits. Don't let
the change in nomenclature fool you, traits are just roles.
"has" in Moose allows you to pass a "traits" parameter for an
attribute. This parameter takes a list of trait names which are
composed into an anonymous metaclass, and that anonymous metaclass is
used for the attribute.
Yes, we still have lots of metaclasses in the background, but they're
managed by Moose for you.
Traits can do anything roles can do. They can add or refine attributes,
wrap methods, provide more methods, define an interface, etc. The only
difference is that you're now changing the attribute metaclass instead
of a user-level class.
DISSECTION
A side-by-side look of the code examples in this recipe and recipe 2
show that defining and using a trait is very similar to a full-blown
metaclass.
package MyApp::Meta::Attribute::Trait::Labeled;
use Moose::Role;
has label => (
is => 'rw',
isa => 'Str',
predicate => 'has_label',
);
Instead of subclassing Moose::Meta::Attribute, we define a role. As
with our metaclass in recipe 2, registering our role allows us to refer
to it by a short name.
package Moose::Meta::Attribute::Custom::Trait::Labeled;
sub register_implementation { 'MyApp::Meta::Attribute::Trait::Labeled' }
Moose looks for the "register_implementation" method in
"Moose::Meta::Attribute::Custom::Trait::$TRAIT_NAME" to find the full
name of the trait.
For the rest of the code, we will only cover what is different from
recipe 2.
has url => (
traits => [qw/Labeled/],
is => 'rw',
isa => 'Str',
label => "The site's URL",
);
Instead of passing a "metaclass" parameter, this time we pass "traits".
This contains a list of trait names. Moose will build an anonymous
attribute metaclass from these traits and use it for this attribute.
Passing a "label" parameter works just as it did with the metaclass
example.
if ( $attribute->does('MyApp::Meta::Attribute::Trait::Labeled')
&& $attribute->has_label ) {
$dump .= $attribute->label;
}
In the metaclass example, we used "$attribute->isa". With a role, we
instead ask if the meta-attribute object "does" the required role. If
it does not do this role, the attribute meta object won't have the
"has_label" method.
That's all. Everything else is the same!
TURNING A METACLASS INTO A TRAIT
"But wait!" you protest. "I've already written all of my extensions as
attribute metaclasses. I don't want to break all that code out there."
Fortunately, you can easily turn a metaclass into a trait and still
provide the original metaclass:
package MyApp::Meta::Attribute::Labeled;
use Moose;
extends 'Moose::Meta::Attribute';
with 'MyApp::Meta::Attribute::Trait::Labeled';
package Moose::Meta::Attribute::Custom::Labeled;
sub register_implementation { 'MyApp::Meta::Attribute::Labeled' }
Unfortunately, going the other way (providing a trait created from a
metaclass) is more tricky.
CONCLUSION
If you're extending your attributes, it's easier and more flexible to
provide composable bits of behavior than to subclass
Moose::Meta::Attribute. Using traits lets you cooperate with other
extensions, either from CPAN or that you might write in the future.
Moose makes it easy to create attribute metaclasses on the fly by
providing a list of trait names to "has" in Moose.
AUTHOR
Moose is maintained by the Moose Cabal, along with the help of many
contributors. See "CABAL" in Moose and "CONTRIBUTORS" in Moose for
details.
COPYRIGHT AND LICENSE
This software is copyright (c) 2012 by Infinity Interactive, Inc..
This is free software; you can redistribute it and/or modify it under
the same terms as the Perl 5 programming language system itself.
perl v5.14.2 2012-02-04 Moose::Cookbook::Meta::Recipe3(3)
