What I don't understand is how you can know that the value of your variable has changed unless you're doing some execution of code within your block. If you're entering a block with a 'my' variable, leaving that block to execute some other code, and returning to it, the variable is recreated and undefined on the 2nd run. Consider:

sub a {
  my $var = 1;

  &b;                   # Can't touch $var

  eval $set_var_to_2;   # Code in this variable can affect $var

  print "$var\n";
}
[download]

Well as it so happens the engineer decide to do some magic to the code. So what I've written wasn't being run as a script but instead being mutilated by his processes and then eval'd. Yeah! :)

Anyway, what was basically going on was that he was chucking a bunch of information in the code to 'massage' it how he needed it to work so that variables could then be exported to all sorts of other places.

Yes this is weird, yes this is definitely not how I'd have even imagined to do it, and yes from now on when I need something fixed in the code I think I'll let him do it and let him have his silly job security.

At least I can safely know that I'm not loosing my mind and forgetting how to program... phew!

It sounds like this guy needs to have his head whacked with a large stick. If you're supposed to be writing code to run within that framework, and you weren't handed an interface specification, something is seriously wrong. If this guy gets hit by a truck tomorrow, where's that company (and their code) going to be?

I'ts my contention if people are doing things *that* evil, with no documentation, then they belong in a research facility, not writing production code. Companies *cannot* afford to be reliant on something like that.

It's not job security, it is a company being held hostage. Demand better.

--Chris

e-mail jcwren