Re^2: Warning for "unused sub declarations"?
by jeffa (Bishop) on May 19, 2005 at 20:15 UTC
|
#use strict;
use warnings;
sub bar {
print $foo;
}
my $foo = 1;
foo();
bar();
sub foo {
print $foo;
}
Now uncomment out the use strict; and run it. FWIW, i do the same as you ... but yes, there are consequences.
| [reply] [d/l] |
|
|
Maybe I'm a little slow, but are you and I talking about two different things? As far as I can tell, your bar routine depends on the global variable $foo which doesn't exist when bar is defined. What I was talking about was the need (or lack thereof) to put a superfluous declaration of all user-defined subs at the beginning of the file.
thor
Feel the white light, the light within
Be your own disciple, fan the sparks of will
For all of us waiting, your kingdom will come
| [reply] |
|
|
Actually ... i was wrong. We are talking about 2 different things. I was thinking that by declaring subs "superfluously" you could
guard against using global lexicals. I thought that was the reason for declaring subs
before hand, other than pseudo-documentation, but turns out i was wrong.
speaking of thor ... here's something amusing ...
| [reply] [d/l] [select] |
Re^2: Warning for "unused sub declarations"?
by chas (Priest) on May 19, 2005 at 20:21 UTC
|
If the sub isn't declared or defined before use, then you
can't call it like a builtin - without & and parentheses around the arguments. That's the main disadvantage for me.
chas | [reply] |
|
|
Fair enough. But, now I'm curious. Since Perl doesn't have type checking, what good does declaring the subroutine get you? Why is perl not able to parse the file, say "hey, chas has subroutines foo, bar, and baz, so if I see them referenced, I'll use them"? Just seems odd to me.
thor
Feel the white light, the light within
Be your own disciple, fan the sparks of will
For all of us waiting, your kingdom will come
| [reply] |
|
|
Reasonable question! I don't know enough about how the parsing/compiling takes place to say. But I suppose it may save some time (i.e. decrease the number of passes) if it is not necessary to look ahead for sub defs. I'll bet someone else around here knows, though. BTW, I usually do like you do and put sub defs at the end (and call with &.) My previous response was just an answer to why someone might declare subs before using; I used to predeclare, but lately it seems more organized to have all the subs defined/declared in just one place (and that outweighs the disadvantages most of the time.)
chas
| [reply] |
|
|
|
|
If the sub isn't declared or defined before use, then you can't call it like a builtin - without & and parentheses around the arguments. That's the main disadvantage for me.
Huh?!? You're joking? Indeed I do declare my subs to be able to call them without parentheses - fair enough. But it is never stressed enough that in Perl5 (as opposed to Perl4 and previous versions) the &-form of of sub call should never ever be used unless you really need it, i.e. you do know what you're doing. See perlsub.
| [reply] |
|
|
It seems to me that people are over-reacting here. I don't generally like to call subs with the ampersand because IMO the code is more readable without it, but honestly, if the other poster wants to write code that calls subroutines using ampersands and parens, I don't see how that will really harm him. Yeah, it suppresses prototypes, but so what? Nobody who needs to be pointed at perlsub is using prototypes anyway.
The only really weird wrinkle with the ampersand sigil
is what happens if you also leave off the parens, but the
other poster specifically said ampersand and parens, so he's not likely to run into that.
"In adjectives, with the addition of inflectional endings, a changeable long vowel (Qamets or Tsere) in an open, propretonic syllable will reduce to Vocal Shewa. This type of change occurs when the open, pretonic syllable of the masculine singular adjective becomes propretonic with the addition of inflectional endings."
— Pratico & Van Pelt, BBHG, p68
| [reply] |
|
|
|
|
|
|
Thanks for the comment; I was aware of the possible pitfalls, but after rereading the docs, I'm rethinking the situation.
chas
| [reply] |
|
|