Re^2: Using variables in array names

Use a "real" hash, instead and you're fine.

I beg to differ. Using a 'real' hash subjects you to some of the same problems you face when using symbolic references. Biggest problem: making typos.

    use warnings;
    no strict 'refs';
    my $point1 = 'valpt';
    @{"use_$point1"} = ("foo", "bar");
    ...
    my $var = 'valpt';  # Oops, typo.
    push @{"use_$var"}, "baz";  # Silently does the wrong thing.

    use strict 'refs';
    my $point1 = 'valpt';
    my %use;
    @{$use{$point1}} = ("foo", "bar");
    ...
    my $var = 'valpt';  # Oops, typo.
    push @{$use{$var}}, "baz";  # Silently does the wrong thing.
[download]

Using hash keys as variable names is only marginally better than using symbolic references. (The advantage mainly being you won't accidentely overwrite important package variables - which in this case, given there are no non-user variables starting with 'use', isn't a serious risk). You still got to be careful to be "fine".

Comment on Re^2: Using variables in array names Download Code

Replies are listed 'Best First'.
Re^3: Using variables in array names by herveus (Prior) on Aug 05, 2005 at 13:30 UTC
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	[reply]
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.	[reply]
Re^5: Using variables in array names by herveus (Prior) on Aug 05, 2005 at 13:57 UTC
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	[reply]
Re^6: Using variables in array names by Anonymous Monk on Aug 05, 2005 at 14:19 UTC
Re^7: Using variables in array names by blazar (Canon) on Aug 05, 2005 at 14:45 UTC
Re^7: Using variables in array names by herveus (Prior) on Aug 05, 2005 at 14:26 UTC
Re^5: Using variables in array names by shemp (Deacon) on Aug 05, 2005 at 17:50 UTC
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!	[reply]
Re^3: Using variables in array names by polypompholyx (Chaplain) on Aug 05, 2005 at 12:57 UTC
In fact they're almost the same, since under the hood, the creation of a symref populates the symbol table, which is 'only' a clever global hash anyway. It'd be interesting to know what the OP wanted to use the code for, since there may well be a nicer solution: the variable names look like they might be something to do with a multidimensional array, which could probably be handled in a tidier way.	[reply]