in reply to Prototype problem

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.

Replies are listed 'Best First'.
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]

      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]

In Section Seekers of Perl Wisdom