I use it for keeping objects internally with implicit error checking as anything uncoercible dies, but not exposing them externally. For a contrived example, something like:
has [ qw/server peer monitor netlog/ ] => ( is => 'ro', isa => 'NetAdd +r::IP', coerce => 1, required => 1 ); coerce 'NetAddr::IP' => from 'Str' => via { NetAddr::IP->new($_, '255. +255.255.255') }; around [ qw/server peer monitor netlog/ ] => sub { my $orig = shift; my $self = shift; my $netaddr_ip = $self->orig(@_); return $netaddr_ip->addr; };
The above accepds valid single IPs (v4 /32 and v6 /128) and passes them back out as addresses, but avoids the default stringification (CIDR notation) the object by default resolves to. Using the lists w/ around is shorter and easier to read as I don't need to make a seperate shim stub for each object's accessor and means it's less likely future refactoring will forget to stringify the accessor appropriately.
However, it's not possible to make a more specific derived class instance with default IPs for some values as it kills the 'around' modifier.
I mean, it's easy enough to say that 'you get an object back, deal with it B)' but if I can inflate passed things to objects as they come in and deflate them back to strings as they go out, why not do it?
Edit:Actually, why not just add a 'decoerce' or 'deflate' or something to the accessor, a coderef that gets run against a value as the value is being returned? It'd allow a (deflate => sub { $_->clone }) to be applied to a DateTime accessor, for example, to make sure a end user doesn't ->add() to your internal value, etc, while not being spooky action at a distance; it's just another attribute of the accessor that can be changed or ignored or overridden by inheriting classes.
In reply to Re^5: Why does changing a Moose attributes' properties remove the around modifier
by mcrose
in thread Why does changing a Moose attributes' properties remove the around modifier
by mcrose
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |