Don't ask to ask, just ask | |
PerlMonks |
Re^5: Why does changing a Moose attributes' properties remove the around modifierby mcrose (Beadle) |
on Jul 18, 2011 at 21:17 UTC ( [id://915283]=note: print w/replies, xml ) | Need Help?? |
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:
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 Section
Seekers of Perl Wisdom
|
|