What I meant, in the short hand, was the variable was defined with "my" inside the while loop.
You need to do that OUTSIDE the while loop, and _yes_ in this case, you _do_ need to pre-declare it, pre-set the scope, or otherwise tell the compiler what to do with the variable before it's actually "used".
Remember, Links SQL needs to be mod_perl compatible, and since you are first using the $output _inside_ a loop, then returning it outside the loop at the end of the routine, you do need to pre-declare it.
"my" sets the scope of the variable. If you don't like the term "pre-declare" then use the term "set the scope" before you use it.
I actually _like_ thinking in terms of pre-declare, since it brings me back to my early days, and it makes sure I have defined, set up, and set the scope on, all the variables I need to use.
Perl allows a lot of bad behavior, and that is good for quick and dirty programs as it was originally set up for, but OO Perl requires a whole different mindset, and programming style.
One of my constructs is I usually set the variables with "my" near where they are first used. But, I _only_ do that if that is only where they are going to be used -- ie: within a few lines of where they were originally declared. If not, I still define them at the top of the program, begining of the loop or block, or where it makes the most sense.
A great example is $sth used as the statement handle. If you only use it in the 2 lines required to set it, and then iterate it, it is fine to declare it with $my where it's first assigned. _but_ if you are going to use it multiple times, or with multiple options, it's better to define it at the top of the block, or subroutine, since it no longer belongs to a single statement, and in trying to maintain the code a few weeks or months later, you will start to wonder where $sth was originally scoped/declared and who owns it.
Most of Perl is creative and liberal use of white space and style. The more consistent you are, the more clear you are, the better your scripts will go together, and the easier they will be to read and maintain.
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
You need to do that OUTSIDE the while loop, and _yes_ in this case, you _do_ need to pre-declare it, pre-set the scope, or otherwise tell the compiler what to do with the variable before it's actually "used".
Remember, Links SQL needs to be mod_perl compatible, and since you are first using the $output _inside_ a loop, then returning it outside the loop at the end of the routine, you do need to pre-declare it.
"my" sets the scope of the variable. If you don't like the term "pre-declare" then use the term "set the scope" before you use it.
I actually _like_ thinking in terms of pre-declare, since it brings me back to my early days, and it makes sure I have defined, set up, and set the scope on, all the variables I need to use.
Perl allows a lot of bad behavior, and that is good for quick and dirty programs as it was originally set up for, but OO Perl requires a whole different mindset, and programming style.
One of my constructs is I usually set the variables with "my" near where they are first used. But, I _only_ do that if that is only where they are going to be used -- ie: within a few lines of where they were originally declared. If not, I still define them at the top of the program, begining of the loop or block, or where it makes the most sense.
A great example is $sth used as the statement handle. If you only use it in the 2 lines required to set it, and then iterate it, it is fine to declare it with $my where it's first assigned. _but_ if you are going to use it multiple times, or with multiple options, it's better to define it at the top of the block, or subroutine, since it no longer belongs to a single statement, and in trying to maintain the code a few weeks or months later, you will start to wonder where $sth was originally scoped/declared and who owns it.
Most of Perl is creative and liberal use of white space and style. The more consistent you are, the more clear you are, the better your scripts will go together, and the easier they will be to read and maintain.
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
