If I had time I'd write up a full description and some comparisons of the techniques and idioms. I don't. :( The good news is the Moose docs are pretty darn good. Start on the main Moose page and then walk through as many of the Moose::Cookbook entries as you can.
The + in the +shift->$method statements is probably too idiomatic to ask you to discover on your own.
my $thing = shift; # ...is equivalent to... my $thing = shift(@_); # ...which is, except for altering @_, functionally equivalent to... my ( $thing ) = @_; # ...or... my $thing = $_[0]; # Perl really is your friend though! # shift without parens can become ambiguous to the interpreter, # not just the next developer! in some cases like... my $lookup = $hash{shift}; # not going to shift(@_) # the unary plus forces shift to be interpreted as the function- my $lookup = $hash{+shift}; # Quick proof- perl -le '%a = (1 => 2, shift => 4); print $a{shift}' 1 4 perl -le '%a = (1 => 2, shift => 4); print $a{+shift}' 1 2 # I think in the cases in the prototype code I showed you # The "+" is not necessary. I use it habitually to visually # disambiguate shift's usage as a function. # This all means that sub o_hai { my $self = shift(@_); return $self->get_some_val(); } # ...is the same as... sub o_hai { +shift->get_some_val; }
Just so you know, many hackers here will tell you that this is suboptimal terrible style. They'd have a case. I find idiomatic Perl easier to read because it's more terse but it is also more confusing to those who don't know Perl idioms. So...
Moose gets conceptually hairy; ask someone to explain the finer points of traits versus roles and the dangers of multiple inheritance to get a feel for that. Moose itself is a joy and, I argue, the clearest path through this problem space and I highly recommend it.
In reply to Re^7: Module Organization
by Your Mother
in thread Module Organization
by Dwood
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |