Re^3: hash key

[Corion]

When you write the following:

$my_hash{"T::c"}

Perl interprets the hash key as the string T::c. The quotes are only there so that Perl knows that you mean the string T::c and not something that Perl could interpret as something else (like a package name, in this case).

Constructing a value that contains quotes will not make the lookup successful because the hash key as interpreted by Perl does not contain quotes.

To look at what Perl sees in a hash, consider using Data::Dumper:

use Data::Dumper;

my %my_hash = (
    '"with_quotes_in_key"'  => 'a value',
    "without_quotes_in_key" => 'another value',
    bare_key                => 'a third value',
    "T::c"                  => 'your value',
    '"Another::thing"'      => 'a fifth value',
);

print Dumper \%my_hash;

[aviw]

TY, solved by $var = "$var".
The issue is that I'm guessing & would like your assistance about it
When the pm file with the hash was created using '::' it was printed with Data::Dumper by the 3rd party code.
It automatically wraps '::' with '"'? to state that it's a string key not a package that should be evaluated - right?
If not kindly explain the logic since I'm missing it.

[AnomalousMonk]

Please see haukex's detailed explanation here. Briefly,  T::c (as a "bareword" literal, without any quotes) is not a "simple identifier"; it will not automatically be stringized to use as a hash key. On the other hand, anything that already is a hash key is a string; hash keys are always and can only be strings. Because hash keys are always strings, data serialization utilities like Data::Dumper will put quotes around them. (How a particular hash key got to be a string in the first place is another story.)

c:\@Work\Perl\monks>perl -wMstrict -MData::Dumper -le
"my %my_hash;
 $my_hash{T::c} = 'xxx';
 print $my_hash{'T::c'};
 print Dumper \%my_hash;
"
Bareword "T::c" not allowed while "strict subs" in use at -e line 1.
Execution of -e aborted due to compilation errors.

c:\@Work\Perl\monks>perl -wMstrict -MData::Dumper -le
"my %my_hash;
 $my_hash{'T::c'} = 'xxx';
 print $my_hash{'T::c'};
 print Dumper \%my_hash;
"
xxx
$VAR1 = {
          'T::c' => 'xxx'
        };

[haukex]

When the pm file with the hash was created using '::' it was printed with Data::Dumper by the 3rd party code.

In your OP you were asking about a string '"T::c"'. I just want to ask to be sure: Are you in any way parsing this Data::Dumper output? If you are, then I think this should be addressed, because manually parsing Data::Dumper output is not a good idea. However, I am not sure if your question is maybe one of simply understanding the Data::Dumper output? In that case, let's say you have output like this:

$VAR1 = {
          foo => "bar",
          "T::c" => "quz"
        };

So if your question is, why is the hash key in the first case without quotes, i.e. my $var = 'foo'; $hash{$var}, and in the second case, why is the hash key not my $var = '"T::c"';, but it is my $var = 'T::c';? The answer to this question is here:

The => operator (sometimes pronounced "fat comma") is a synonym for the comma except that it causes a word on its left to be interpreted as a string if it begins with a letter or underscore and is composed only of letters, digits and underscores. This includes operands that might otherwise be interpreted as operators, constants, single number v-strings or function calls. If in doubt about this behavior, the left operand can be quoted explicitly.

These rules for when the left-hand side of a fat comma is autoquoted are basically the same as the ones for hash subscripts, which I discussed at length here. In short, writing ( foo => "bar" ) is exactly the same as writing ( "foo" => "bar" ). However, ( T::c => "quz" ) is not the same as ( "T::c" => "quz" ), because T::c will not be autoquoted according to the above rules. Data::Dumper knows all of this, and, with the appropriate options set, will generate the output I show above, only quoting hash keys when it is necessary.

solved by $var = "$var"

Note that if $var is already a string, then $var="$var"; will not really do anything and can be left out.