# from Ovid
# on Thursday 09 September 2010 23:15:
> sub foo {
> my $self = shift;
> my ($name) = @_;
>...
>I know this formatting is common, but what practical benefit does it
> gain? ... I'm
> unsure what "value" this provides other than conforming to a
> particular coding preference (and it's more ops, but that's probably
> not enough for it to be a performance win to avoid it).
It's adds clarity (yes, at the cost of an op) and makes the method stand
out as such, since we're lacking a 'method' keyword. Though I guess
you could say:
sub foo {
my ($self,
$name, $thing, $deal) = @_;
...
and get the "stand out" effect without the op cost.
But then the parentheses will likely become troublesome. As in:
sub foo {
my $self = shift;
croak("odd number of arguments") if @_ % 2;
my %args = @_;
...
So, starting a method with 'my $self = shift;' gets it out of the way on
one line, and anything involving the parameter list is separate, which
makes it easier to change the code regarding the parameter list
without having to restructure around the invocant being nested in one
long 'my ($self, $name, ...) = @_' statement. That is, when I'm
working with code which doesn't use the 'my $self = shift;' idiom to
start a method, I find that I have to do some character editing there
when something changes. Whereas with the idiom, this sort of thing
tends to involve linewise editing (shovel vs bulldozer.)
So, say the first half of the innards of foo() are being refactored to
bar(), which will also take the original parameters in the same form:
sub foo {
my $self = shift;
my %bar = $self->bar(@_);
...
Had that been 'sub foo { my ($self, ...) = @_', you might started with:
sub foo {
my %bar = shift->bar(@_);
...
# but we need $self here
And now you have to go back and write it as 'my $self = shift' anyway.
Or I could have said something about keeping yourself from accidentally
overwriting $_[0].
--Eric
--
The only thing that could save UNIX at this late date would be a new $30
shareware version that runs on an unexpanded Commodore 64.
--Don Lancaster (1991)
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
