in reply to Re: Structural Elegance
in thread Structural Elegance

That sounds suspiciously like "tramp data." Tramp data is data that is passed, unused, through a call chain so that the later methods/subroutines can get access to it. This is a Bad Thing. Your code becomes more difficult to refactor because subs now take extraneous arguments. Also, if you accidently munge the data, it can be difficult to track down where this happened.

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