in reply to Re^2: Using variables in array names
in thread Using variables in array names

Howdy!

Beg all you want. You won't get any... :)

Using hash keys with variable names is so much safer than using symbolic references. The biggest problem with symbolic references is polluting the package namespace.

If you have a data structure with elements whose name is only going to be known at runtime, you have little choice but to use a hash. It's the "right" data structure to use. You have to be responsible for the integrity of the way you manage your keys.

yours,
Michael

Replies are listed 'Best First'.
Re^4: Using variables in array names
by Anonymous Monk on Aug 05, 2005 at 13:42 UTC
    The biggest problem with symbolic references is polluting the package namespace.
    I addressed that in my reply, and IMNSHO, that isn't the biggest problem. The vast majority of the problems I've seen when people use symbolic references (and when you give Perl classes you see a lot) stem from typos - not from "polluting" the package namespace.
      Howdy!

      OK. But that doesn't make the solution invalid. It more likely suggests that the people getting into trouble from using symbolic references are both inexperienced and ignorant.

      The basic fact remains that hashes are the Right Tool for managing a collection of items identified by an arbitrary string. Your initial response conveyed the impression that you would deprecate using hashes with variable keys entirely, which, IMO, is absurd.

      yours,
      Michael
        But that doesn't make the solution invalid.
        No, and I never claimed it was invalid. I just objected to the phrasing that "you will be fine" - as it suggests you're suddenly immune from the perils of symbolic references. That's what I objected to.
      In regard to typos in hash keys, i have used various tied hashes that require registering any key before it is used. The definition of 'used' varies from implementation to implementation. In some cases i'd let it ask for existence of a non-registered key, but in other implementations, any action on a non-registered key is fatal. Etc, Etc, Etc.

      My use of this approach is pretty rare, and is not perfect because its run-time checks, but in certain critical apps (such as bulk changes to my data warehouse) this approach can be advantageous.

      I guess it comes down to a trade off of ease of use vs. level of checking.


      I use the most powerful debugger available: print!