Prototype problem

nlafferty has asked for the wisdom of the Perl Monks concerning the following question:

I can't seem to figure out prototyping. I had thought that I was doing it correctly but i get errors.

Global symbol "$min" requires explicit package name at /home/httpd/cgi-bin/nick/timeclock/strict/timeclock.cgi line 55.
Global symbol "$hour" requires explicit package name at /home/httpd/cgi-bin/nick/timeclock/strict/timeclock.cgi line 55.
Global symbol "$day" requires explicit package name at /home/httpd/cgi-bin/nick/timeclock/strict/timeclock.cgi line 55.
Global symbol "$month" requires explicit package name at /home/httpd/cgi-bin/nick/timeclock/strict/timeclock.cgi line 55.
Global symbol "$year" requires explicit package name at /home/httpd/cgi-bin/nick/timeclock/strict/timeclock.cgi line 55.
Global symbol "$calc_year" requires explicit package name at /home/httpd/cgi-bin/nick/timeclock/strict/timeclock.cgi line 55.
Global symbol "$calc_month" requires explicit package name at /home/httpd/cgi-bin/nick/timeclock/strict/timeclock.cgi line 55.

####################### GET TIME AND DATE FOR IN FORM
my ($time, $date);
sub in_time_date ($$$$$$$){
my ($min, $hour, $day, $month, $year, $calc_year, $calc_month) = @_;
($min, $hour, $day, $month, $year) = (localtime)[1,2,3,4,5];
($calc_year, $calc_month);
$calc_year        = $year+1900;
$calc_month     = $month+1;
$date = "$calc_year-$calc_month-$day";
$time = sprintf("%d:%02d", $hour,$min);
}
####################### END GET TIME AND DATE FOR IN FORM

in_time_date($min, $hour, $day, $month, $year, $calc_year, $calc_month
+);
[download]

Comment on Prototype problem Download Code

Replies are listed 'Best First'.
Re: Prototype problem by kwoff (Friar) on Jan 01, 2002 at 00:52 UTC
It's not a prototyping problem, it's a scope problem. You declared: `my ($min, $hour, $day, $month, $year, $calc_year, $calc_month);` within `sub in_time_date` but didn't declare the variables outside that subroutine.	[reply] [d/l] [select]
Re: Prototype problem by steves (Curate) on Jan 01, 2002 at 00:56 UTC
I think your problem is with scoping -- not prototyping. Line 55 would be that call to in_time_date() no doubt. You are passing in 7 variables that aren't defined anywhere. The ones with the same names and my lexical scoping in the function itself are different variables, private to that function. Perl will assume any undeclared variables are package variables, so it wants you to explicitly tell it where they're declared. If you turn off strict checking it will happily assume they're in the current package and create them on the fly. I wouldn't recommend this personally though -- I prefer explicit scoping and strict to avoid unexpected side effects.	[reply]
Re: Re: Prototype problem by nlafferty (Scribe) on Jan 01, 2002 at 00:59 UTC
Now that makes perfect sense. I suspected that the would have to be declared before a called them in the sub. Do I still declare them with my inside the sub?	[reply]
Re: Re: Re: Prototype problem by steves (Curate) on Jan 01, 2002 at 08:04 UTC
See if you can get a good Perl book to read about scoping. There's scope within any set of curly braces {} or within a single file outside of all curly's (nyuk, nyuk, nyuk). So you have a set being passed from that outside scope to the scope inside the function, which is assigning what's passed to it. The easiest thing, and probably what you want, is to declare them all with my at the top of the file in addition to the ones in the sub. The reason for the two sets of declarations is the same as for any other programming language: The function is general purpose so it takes what's passed to it and keeps a copy to work on for each call (thereby also allowing simultaneous threaded calls); the outside caller has values it got from somewhere else that it wants the function to return a result for.	[reply]
Re (tilly) 1: Prototype problem by tilly (Archbishop) on Jan 06, 2002 at 06:13 UTC
There has been past discussion about whether to use prototypes, for instance at When to use Prototypes?. Most of it centers around the extremely detailed and accurate criticism at Tom Christiansen's Far More Than You've Ever Wanted To Know About Prototypes. Suffice it to say that prototypes in Perl probably don't do what you want them to, and you are probably best off just trying to forget that they exist.	[reply]


Welcome to the Monastery
	PerlMonks