Instead, use access subroutines to handle this:
my $TRAMP; sub my_data { $TRAMP = shift if @_; return $TRAMP; } You can then take the variable out of the call chain. Later, if you find something is altering this data in an unexpected manner, you can put data validation here, dump stack traces, etc.
This is just using a function call to re-implement a global variable. Perl has real built in globals. Use them.
I've seen sooo many people try to dodge using global variables, then ending up with an obfuscated version of the same thing.
"No, it's not a global: it's a single hash that contains all our data, passed down to every function".
"It's not a global, it's stateful accessor function"
"It's not a global, it's a class method" (but used maintain state information about unrelated objects)
"It's not a global, it's a tied hash that references a accessor function" (my favourite)
And so on, ad naseum.
The K.I.S.S. principle says that if you need to store global data, just put it in a global variable, unless you have a good reason not to. If you're shoving too many things down your call stack, perhaps you need to re-design your call stack. I'm very much a fan of using the scope you need, rather than jumping through hoops to avoid it because of some "rule" that says globals are always bad.
Unnecessary use of globals is very bad: avoiding globals when they're useful or necesseary is just as bad.
End of rant.
--
AC
In reply to Re^2: Structural Elegance
by Anonymous Monk
in thread Structural Elegance
by samizdat
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |