Re^2: Best practices

"don't use global variables".

I have to comment that our variables are far from globals. It is impossible to keep all data in function parameters. If you are passing refs you are reinventing globals :-) Passing refs automatically by the compiler is called OOP.

I will use "goto" and "our" without any pain and I also put parentheses in a "wrong" line. With perl you can do it in many ways but I am still missing inline functions.

Comment on Re^2: Best practices - if any?

Replies are listed 'Best First'.
Re^3: Best practices - if any? by tfrayner (Curate) on Feb 22, 2010 at 13:13 UTC
I must have been dreaming all these years I've kept all my data in function parameters. As for passing refs reinventing globals, I think you're mistaken. Maybe it makes sense if you're in the habit of addressing your variables by memory location (as in C; pointer arithmetic, for example). The only time a reference is global in Perl is if you've stored it in a global variable (although I'm sure someone is going to pop up with a counter-example). However, disregard that argument for a moment. You're definitely missing one of the key advantages of parameter passing - it effectively documents the flow of a variable through your code, so that when you change a variable you can trace the effects of that change. The problem with globals is that you can change the value of a variable and then find it hard to figure out what's affected downstream; and the bigger the codebase grows, the harder it becomes. Tim	[reply]
Re^4: Best practices - if any? by AriSoft (Sexton) on Feb 22, 2010 at 15:29 UTC
"when you change a variable you can trace the effects of that change" I forget so tell that this program is using threads and flow of control is made by locks, not by function parameters. I had to create a shared locking module to allow read by many write by one type access control. (At least I did not find suitable from CPAN.) Some of us are putting global variables to a database - do you believe that?	[reply]