in reply to Re: Dynamic variables
in thread Dynamic variables

I must say, while your advice (to use a hash) seems perfectly sensible, I'm sort of confused about why you used a hashref instead of a plain hash. Also, you included some superfluous punctuation between the nested subscripts in your assignments. Do you just like typing the arrow operator that much? :-)

Here's how I'd have done it. Not all that different, but sometimes small things can make a difference:

my %max;
$max{george}{money} = 100;
$max{george}{budget} = 100;
my $person = "lindsay";
$max{$person}{money} = 1500;
$max{$person}{budget} = 2000;

for ("george","lindsay") {
   printf "%s's money= %d\n", $_, $max{$_}{money};
}

[download]

Replies are listed 'Best First'.
Re^3: Dynamic variables
by eric256 (Parson) on Jul 22, 2004 at 19:00 UTC

    I prefer a hashref for many reasons but mostly just because its what i've always used and i came from a VB + C background where -> doesn't seem like all that much to type. It makes it clear to me whats going on and I don't mind the two extra key strokes. BTW is there a reason to use a regular hash instead of a ref? The -> also makes it feel more like a pointer so it flows with my way of thinking better. I'm not sure there are any real advantages speed or functionality wise to pick between using it or not though.


    ___________
    Eric Hodges
[reply]

      I like using plain hashes unless necessary. The same goes with arrays, and subroutines. References are extremely useful tools, but using them for everything seems a bit silly.

      What are my reasons? Well, one might be overhead. There is a small amount of overhead involved in dereferencing, though to be honest this doesn't concern me that much.

      A much more important reason is tidiness. All those arrows do not take long to type, and they don't really make it extremely difficult to read, but they do add some noise. Frankly, I think we should take advantage of any decrease we can get, in terms of visual noise. Consider the following examples:

          @{$href}{"one", "two", "three"}; # hash slice, hashref
    @hash   {"one", "two", "three"}; # hash slice, hash

    for (0 .. $#{$aref}) {} # index iteration, arrayref
    for (0 .. $#array)   {} # index iteration, array

    # with references
    @{$aref2} = map  { $href1->{$_} + 1 }
                sort { $href2->{$a} <=> $href2->{$b} }
                grep /foo/, @{$aref1}[0 .. $#{$aref1}/2];

    # without
    @array2 = map  { $hash1{$_} + 1 }
              sort { $hash2{$a} <=> $hash2{$b} }
              grep /foo/, @array1[0 .. $#array1/2];

      [download]

      Sure, the versions using references aren't terribly much more difficult to follow than the ones without. It's not that big of a difference, but like I've said before, every little bit helps. This kind of thing adds up quickly to create a mess.

[reply]
[d/l]
        I find that, especially with complex data structures, the -> notation can clarify things by seperating my identifiers.

        You also pick as examples of dereferencing notations that can tend to look complex to an inexperienced programmer whether they are references or not. All of the examples you cite for complexity can be rewritten using less confusing notations. 

        for (0 .. $#{$aref}) {}
# or
for (@$aref) {}

@{$aref2} = ...;
#or
@$aref2 = ...;

        [download]
        I'm not sure why you don't show that the curly braces can be left out during dereferencing.
        dsb
        This is my cool %SIG
[reply]
[d/l]

In Section Seekers of Perl Wisdom