in reply to Hash assignment: Undocumented feature?

see perldata:
If a key appears more than once in the initializer list of a hash, the last occurrence wins:
  • Comment on Re: Hash assignment: Undocumented feature?

Replies are listed 'Best First'.
Re^2: Hash assignment: Undocumented feature?
by fsavigny (Novice) on Aug 11, 2013 at 16:51 UTC

    Thanks very much! That should put me to shame, and it's right; on http://perldoc.perl.org/perldata.html, there it is. My Gentoo, though constantly updated, seems to have an outdated version of perldata (v5.12.4, dated 2011-06-07), which does definitely not contain this information (there is also no %circle hash with different radii).

    But surely this must have been like that for longer than two years???

    (I hope I will be able to give a good example for why I think it's useful, but I'm having to dash off right now.)

      Perhaps you're new enough to the concept of a hash to not fully understand that any hash "bucket" acts the same as an array "bucket". In other words,
          $hash{'bucket'} = 'something';
      is similar in concept to
          $array[5]='something';

      If you then, say
          $array[5]='something else';
      hopefully you understand that $array[5] has been written over with the new information; just extend that concept to
          $hash{'bucket'} = 'something else';

      So, no this is not new behavior, but the way hashes, across all the languages that implement some sort of hash, are supposed to work.

      -Scott

        No, no. I am not surprised at all (nor new to the fact) that $hash{'bucket'} = 'something'; overwrites anything that took 'something''s place before. (I thought I had hinted as much in my original post; sorry if that wasn't clear enough.) That was in fact the one and only way of modifying a hash value I knew.

        For that reason, it was clear to me that if you specify a key twice, one of them must have to go, since otherwise, the hash is no longer a hash. But it wasn't obvious to me which of the values would prevail. Even though the last one is arguably the most intuitive choice, I wouldn't have wanted to bank on it.

        What contributed to my wondering was probably this easy interchangeability of arrays and hashes: ('foo', 2, 'bar', 'pepper') can be assigned to @some_array_variable or %some_hash_variable, or you could assign it to the former and then say %some_hash_variable = @some_array_variable. But

        %some_hash_variable = ('foo', 2, 'bar', 'pepper', 'foo', 4); # is crucially different from @some_array_variable = ('foo', 2, 'bar', 'pepper', 'foo', 4);

        That's what I found interesting about it, and no, I did not find it completely obvious which value %some_hash_variable would have. (My secret motto is "You never know with Perl".) But now I know. It's a nice feature, and now I can rely on it.

        Bucket has a special meaning to hash tables, what hashes implement. You are talking about elements of hashes and arrays.
      > But surely this must have been like that for longer than two years???

      Yes, but seems indeed documented only in perl 5.18.

      IMHO this feature used _very_ often. And works like that for ages. So don't worry.