Ok, this is a potential solution. However (final neurosis question), I'm concerned about speed. Alot of tied hashes are going to be created in the context of a single web hit. Isn't that going to be slower than using regular hashes? (I suppose this is a classic tradeoff issue: raw speed vs. maintainability.)

thanks all,
MFN

Please don't concern yourself with that ahead of time. If you write the code and find it to be too slow, then profile it to find out where the real bottleneck is. Programmers are notoriously useless in predicting which parts of their code will consume the most time, so concentrate on constructing something correct, readable, maintainable, simple, clear, and only concern yourself with speed once you find that performance is insufficient. Then, measure which part of your code actually needs acceleration, and work on that. Chances are it will be something completely different than what you expected.

It is easier to optimize correct code than to correct optimized code.

Makeshifts last the longest.

ManFromNeptune,
Hash keys are case sensitive. To make something that looks and feels like a hash, but is case insensitive takes overhead. There is no way to get around that.

It might be worth while to keep in mind that your approach to solving a problem is unlikely to be the same as people with more experience. If you only ask how to accomplish your approach without stating the underlying problem, we are locked in without anyway of providing better, alternative advice.

Cheers - L~R

I have not thought this through completely, but you could use a tied hash which on STORE used a lowercase function. This would alleviate the need to have a lc() all over the code but it would slow your code down a bit. Again, this is off the top of my head so it might not work.