|
in reply to Preferred technique for named subroutine parameters?
I, too, dislike having bunches of curly brackets cluttering up my code.
However, the
func({ key1 => 'value1', key2 => 'etc', });
invocation style for named arguments has a benefit I consider very valuable: if an invocation is malformed, a warning is issued at the point of invocation.
In the alternate, arguably cleaner, invocation style that does not use an anonymous hash, the warning is issued at a point within the called function, so the question immediately becomes "Where was this function invoked, so I can go there and fix the improperly specified arguments".
use warnings;
use strict;
func_1({ one => 'uno', two => 'dos', three => }); # <-- line 38
func_2(one => 'uno', two => 'dos', three => );
sub func_1 {
my %args = %{ $_[0] };
print "func_1: one translates to $args{one} \n";
}
sub func_2 {
my %args = @_; # <-- line 48
print "func_2: one translates to $args{one} \n";
}
Output:
>perl 765727_1.pl
Odd number of elements in anonymous hash at 765727_1.pl line 38.
func_1: one translates to uno
Odd number of elements in hash assignment at 765727_1.pl line 48.
func_2: one translates to uno
|
Re^2: Preferred technique for named subroutine parameters?
by akho (Hermit) on May 22, 2009 at 20:28 UTC
|
That's because you are doing it wrong. Carp is your friend:
use warnings;
use strict;
use Carp;
func(one => 'uno', two => 'dos', three => );
sub func {
croak "wrong number of arguments for func(); has to be even" if sc
+alar(@_) % 2;
my %args = @_;
print "func: one translates to $args{one} \n";
}
prints
wrong number of arguments for func(); has to be even at a.pl line 8
main::func('one', 'uno', 'two', 'dos', 'three') called at a.pl lin
+e 5
| [reply]
[d/l]
[select] |
|
|
I happen to like Carp so much that I rewrote it to make it better, but try as it might it cannot always properly assign blame. In this case it reaches all of the way up the call stack, gives up, and gives a complete stack backtrace. If your code appeared in a module, you'd have blamed the user with a very confusing message.
By contrast the anonymous hash always blames the exact right line of code.
While I have preferred the flat list approach, I'm going to have to rethink that preference based on this point.
| [reply] |
|
|
Quite the opposite: moving func to a separate module makes Carp work.
And it gives an error that is more specific (for example, it includes the name of the function) than the generic message returned by the anonymous hash.
Besides, it actually dies, not prints something and then goes on as if nothing happened.
| [reply] |
|
|
|
|
|
|
| |
|
|
|
| [reply]
[d/l]
[select] |
|
|
| [reply] |
|
|
Re^2: Preferred technique for named subroutine parameters?
by shmem (Chancellor) on May 23, 2009 at 10:08 UTC
|
Valid point, but Carp::cluck tells you of the invocation point, also. If you would want that globally, you could $SIG{__WARN__} = \&Carp::cluck and comment that out in the final version.
Too expensive for me if there's no other reason to pass named parameters as an anonymous hash:
use Benchmark qw(cmpthese);
sub f{}
cmpthese (
-1 => {
list => sub { f( foo => 1) },
ref => sub { f({foo => 1})},
}
);
__END__
Rate ref list
ref 232162/s -- -88%
list 1989486/s 757% --
Contructing and destructing a full blown hash only to pass named parameters is just a waste. Breaking named parameters into several lines aligning the fat commata vertically helps. I did commit the gaffe of passing an odd number of arguments as named subroutine parameters maybe twice in all my time as a perl programmer, but more often I've been bitten by missing the curlies for apis which required a hash ref for named parameters. | [reply]
[d/l]
[select] |
|
|
My benchmark foo is very poor but does this show that if you do something with the arguments the "waste" is not as dramatic as your figures show?
#!/usr/bin/perl
use strict;
use warnings;
use Benchmark qw(cmpthese);
sub f{
my %hash = @_;
my $value = $hash{foo};
}
sub g{
my $hash_ref = shift;
my $value = $hash_ref->{foo}
}
cmpthese (
-1 => {
list => sub { f( foo => 1) },
ref => sub { g({foo => 1})},
}
);
__END__
Rate ref list
ref 693652/s -- -25%
list 919951/s 33% --
| [reply]
[d/l] |
|
|
Yes, of course. Your benchmark is even more appropriate to show the overhead, which consists in creating, populating and destroying a hash (call with hashref) vs. populating a hash already allocated on the subroutine's pad (call with list).
Might be small, but might sum up. Call it a micro-de-optimization, but I see no value in making perl slower for a questionable gain and a loss of readability.
| [reply] |
Re^2: Preferred technique for named subroutine parameters?
by LanX (Saint) on May 23, 2009 at 15:13 UTC
|
> a warning is issued at the point of invocation.
well the argument in PPP is much stronger, the warning is issued at compile-time !!!
The point of invocation can still be found out in run-time, e.g. with carp like already discused!
But a run-time-error can happen years after you wrote and sold the code ...
| [reply] |
|
|
... the argument in PPP is much stronger, the warning is issued at compile-time !!!
My PBP (1st English ed., printed July 2005, which seems from the O'Reilly website info to be the latest English edition and printing) does say (pg. 183, 2nd para.) "... will be reported (usually at compile time) in the caller's context ...", but I don't see how this is so. (I have also checked the on-line errata list and there is no correction of this statement.)
Certainly the malformed function call
func_1({ one => 'uno', two => 'dos', three => });
from my example code in Re: Preferred technique for named subroutine parameters? does compile and only warns at run time.
Can you give an example of a compile time error associated with this invocation format, or any explanation or example of what Conway was referring to?
But a run-time-error can happen years after you wrote and sold the code ...
True, but if it does happen years after I wrote and sold the code, cashed the check, spent the money and moved to another state ...
Update: "edition" -> "edition and printing" in para. 1.
| [reply]
[d/l] |
|
|
Hi
Certainly the malformed function call
func_1({ one => 'uno', two => 'dos', three => });
from my example code in Re: Preferred technique for named subroutine parameters? does compile and only warns at run time.
Can you give an example of a compile time error associated with this invocation format, or any explanation or example of what Conway was referring to?
Wow, no! And I have troubles to imagine a construction where you get a compile-time error/warning for a anonymous hash which wouldn't also be thrown in a simple parameter list!
I simply trusted TheDamian, in my a German copy the passage first says something like "(normally during compilation)" and four lines later it contrast the counterexample with "only at run-time".
The example given is certainly a run-time warning in both cases!
Maybe you should open a new thread and ask the community for wisdom.
UPDATE: concerning PPP
For those who might think "Pest" means "Best" in German, no it doesn't! Both words have identical meanings and spelling in either language, it's a joke in the current German edition, which accidentally got printed on the backcover! 8 )
| [reply] |
|
|
