1) tie %ENV, 'my_uppercase_env';
2) just simple access methods Eget, Eset, Edel, Eexs
3) Define some intermediate %ENV_, tie it, and in its methods do with real %ENV
is a trade-off between the effort to implement the solution and the effort to adapt the (existing?) code that expects case-insensitive access to %ENV.
1) is the hardest one to implement, as you have noted. %ENV is magical, and tie-ing a magical variable is bound to be tricky. On the other hand, it requires no change at all to the code that uses it. You'd need that method if you can't change that code at all. If you can, choose one of the others.
2) is the simplest one to implement, but it would presumably require hand-editing the code that uses it, replacing every access to %ENV with the appropriate access method.
3) is in effect a wrapper around 2). It needs extra effort to embed the access methods in a tied hash. The advantage would be that you could mechanically change the using code, applying something like s/([%@$])ENV/${1}ENV_/g.
In this view, the choice would depend on how hard it is to adapt the code that needs a caseless %ENV.
Anno
In reply to Re: Case insensitive keys in global %ENV
by Anno
in thread Case insensitive keys in global %ENV
by bdimych
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |