&foo;
sub foo { print "Hello\n" }
Perl will interpret a bareword as a subroutine call with no arguments, but then you have to make sure that perl knows your bareword is a subroutine:
foo; # does not call foo()
sub foo { print "Hello\n" }
foo; # calls foo()
| [reply]
[d/l]
[select] |
Be very careful with &foo;. This is a powerful, but dangerous way to call a function and should only be done when the special semantics are intended.
Powerful? Dangerous? Special semantics? This form of sub call will automagically grab the current @_ for its arguments. Combine that with Perl's pass by reference subroutines and serious weirdness may ensue.
See Messing with @_ for an example of how this can be used and/or abused.
| [reply] |
&foo;
&foo(@_);
foo(@_);
Therefore, &foo; should be used with care (passing @_ explicitly is much more friendly, IMHO).
Update: chromatic is right, I should've checked perlsub before posting. | [reply]
[d/l]
[select] |
| [reply]
[d/l]
[select] |
Read the free document, perlsub.
The Perl Best Practices book also has a section making recommendations on usage. It's not as free, but it is worth the small investment, in my opinion.
| [reply] |
What does reading the documentation lead you to believe? I mean it's not like the synopsis itself answers this question or anything . . .
The cake is a lie.
The cake is a lie.
The cake is a lie.
| [reply] |
To avoid confusion, in gui code you will often see the &somesub syntax,
because often gui's will automatically pass the calling widget as it's first argument to the sub, and the & supresses it. Like:
-command=>[\&raiseit,$win])
# passes $win as first arg
# instead of widget or event
# not a 100% foolproof rule
So, even though the somesub() syntax is preferred ( and most correct), be prepared to see other weird constructs.
Everytime I write a sub, I usually put
sub somesub{
print "@_\n";
....
....
}
as it's first line, just to be sure what I'm getting. Sometimes I surprised by what comes in.
| [reply]
[d/l]
[select] |