damian has asked for the wisdom of the Perl Monks concerning the following question:
am having trouble with this one... is this correct? will this code
parse the subroutines if a variable is defined?
if(defined($afile)) { &parse_recent; &parse_monthly; &parse_new; &crea
+te_temp_a; ©_new_to_recent; ©_recent_to_monthly; &remove_exce
+ss; &done; }
if(defined($bfile)) { &parse_recent; &parse_monthly; &parse_new; &crea
+te_temp_b; ©_new_to_recent; ©_recent_to_monthly; &remove_exce
+ss; &done; }
if(defined($cfile)) { &parse_recent; &parse_monthly; &parse_new; &crea
+te_temp_c; ©_new_to_recent; ©_recent_to_monthly; &remove_exce
+ss; &done; }
if(defined($dfile)) { &parse_recent; &parse_monthly; &parse_new; &crea
+te_temp_d; ©_new_to_recent; ©_recent_to_monthly; &remove_exce
+ss; &done; }
thanks in advance.
(Ovid) Re: is this correct?
by Ovid (Cardinal) on Aug 10, 2000 at 09:13 UTC
|
Not sure what your problem is with this, but you might find the following code a little cleaner:
foreach $file ($afile, $bfile, $cfile, $dfile) {
if (defined $file) {
&parse_recent;
&parse_monthly;
&parse_new;
&create_temp_a;
©_new_to_recent;
©_recent_to_monthly;
&remove_excess;
&done;
}
}
Other than needless duplication, your code is fine. My only concern would be the &subname syntax. When calling a sub with and ampersand prefix and not passing any arguments, the current value of @_ is passed to the sub. This is useful if you are calling subs from subs and need to keep the original passed parameters.
The danger is, if you're not aware of this and you have something in your @_ array, calling a sub this way may generate unexpected results. You're calling many subs with this syntax and if any of them are doing something unusual if the @_ array is empty, you may have a problem.
Here's an example:
&sub1("Good");
sub sub1 {
&sub2;
}
sub sub2 {
my $var = shift;
print "We're having an argument: $var.\n" if defined $var;
}
Guess what? It prints "We're having an argument: Good." even though casual examination suggests that no argument was passed. It's safer to call the sub as subname() or simply call it with a bare subname (which I wouldn't suggest as that means you aren't using strict.
Other than that, nothing more to offer. Give us more detail on your problem and we'll try to help.
Cheers,
Ovid | [reply] [d/l] [select] |
|
That bit about bare subnames made me question my thoughts on the subject, so I whipped up a little test:
#!/usr/bin/perl -w
use strict;
fight;
win;
sub fight {
print "Fighting!\n";
}
sub win {
print "Winning!\n";
}
Compile time errors about barewords. Now move the sub definitions up:
#!/usr/bin/perl -w
use strict;
sub fight {
print "Fighting!\n";
}
sub win {
print "Winning!\n";
}
fight;
win;
Works fine. One more try:
#!/usr/bin/perl -w
use strict;
use subs qw ( fight win );
fight;
win;
sub fight {
print "Fighting!\n";
}
sub win {
print "Winning!\n";
}
There. While I definitely recommend putting the braces () on the end of any subroutine name for the sake of code clarity, if a bareword can be resolved to a known subroutine name, whether defined in your package or imported via use or require or eval, the compiler won't throw an error. That's probably more specific than anyone wants to know, though.
Update: Yes, because require and eval work at run-time (not compile time), they need to be in a BEGIN block. Sorry for being unclear. | [reply] [d/l] [select] |
|
I don't think that require or eval will cut it.
What is going on is that Perl will not complain if it has
already compiled the fact that you have subroutines when
you hit the bareword. Since strict creates a compile
time complaint, it will fail without ever paying any
attention to require or eval. (Unless, of course
they are in a BEGIN block.)
This actually gets at some important points. The same
behaviour that you see with strict comes up again with
prototypes.
Here is the underlying cause.
When perl (not a typo, the language is Perl, the interpreter
is perl) sees your script it fundamentally has 2 different
things that it does. The first is it compiles code to an
internal representation, the second is that it runs that
internal representation. These take place in separate
passes. However some things will cause it to switch from
one to the other.
While compiling if Perl sees certain things, for instance
a complete BEGIN block or use, it will switch out of
compiling your script to go do something else and then
return to your script when it is done that. Conversely
while running if your program encounters other things,
for instance require and eval, it may have to go back
to compiling more code.
Now the (obvious) rule is that at no point can you take
into account code that you have not (yet) compiled. By
the time your main script gets around to running, most
stuff has compiled, and it just works. But if the code
affects compilation in some way (eg telling Perl that a
sub really exists, or declaring a prototype for a
subroutine) then it cannot take effect until *after* Perl
has seen that text.
Does that make sense?
| [reply] |
|
hi ovid, guys,
basically my problem with this is that if $afile only is defined,
it proccess the following subroutines, but if i have $afile, $bfile
defined it does not proccess $bfile.
i am not sure if it is the code.
thanks again.
| [reply] |
|
It sounds to me like you want this, but i'm not really sure?
if( (defined $afile) && !(defined $bfile) )
{
&parse_recent;
&parse_monthly;
&parse_new;
&create_temp_a;
©_new_to_recent;
©_recent_to_monthly;
&remove_excess;
&done;
} elsif( (defined $bfile) && !(defined $afile) )
{
&parse_recent;
&parse_monthly;
&parse_new;
&create_temp_a;
©_new_to_recent;
©_recent_to_monthly;
&remove_excess;
&done;
}
______________________________________________
|_____¸.·ooO--(> cRaZy is co01. <)--Ooo·.¸_____|
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ | [reply] [d/l] |
|
if i have $afile, $bfile defined it does not proccess $bfile
damian: we don't have enough information here to tell you what's going on. On the surface, your code should work. Are you getting any error messages or is your code silently going along and doing stuff without complaining? If you're not getting error messages, I suggest four courses of action:
- Go over your subs and see if your setting any global vars that you use as conditionals. If so, the next time you encounter them, your subs may see them and not execute desired code.
- Read Using the Perl Debugger and try it out on your code. It's a bit more work up front, but I guarantee that the debugger will become one your best friends in the future.
- Verify the you are checking the return codes whenever you open or close a file. For example: open FILE, $file or die "Can't open $file: $!\n". That $! will hold your error code. If you don't check the return codes, you will have no idea whether or not your file manipulations worked.
- And for last, here's my guess as to your problem: I suspect for your code that if $bfile is defined that your sub such as &parse_recent and &parse_monthly are supposed to act on $bfile. However, it's not clear from your code how you are passing the appropriate file to the subs. Are they just acting on $afile all the time?
Hope this helps.
Cheers,
Ovid
| [reply] |
(crazyinsomniac) Re: is this correct?
by crazyinsomniac (Prior) on Aug 10, 2000 at 08:22 UTC
|
It will execute the subroutines if those variables are defined.
What kind of trouble are you having?
______________________________________________
|_____¸.·ooO--(> cRaZy is co01. <)--Ooo·.¸_____|
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ | [reply] |
|
|