in reply to
Putting an array into a hash gives an unexpected reference to the hash itself.
... I am still puzzled as to why I got a reference to the hash value 'email' => $services{'service1'}{'email'} rather than a reference to say 'email' => $maintainers[0];
The problem is that Dump() does not 'know' that the reference that is the value of both $services{service1}{email} and $services{service2}{email} derives from the @maintainers array, i.e., \@maintainers (not the $maintainers[0] array element). All Dump() 'knows' is that one reference in the data structure it is analyzing (by recursive traversal of a tree of references!) is the same as another, and it tries to let you know (without quotation marks) this because it's probably significant. (Perl has a great deal of introspective ability, so it might be possible (but probably not – see Update below) to make a function like Dump() smart enough figure out the name of the original referent (if it ever had and still has a name!), but if it is, the author of the module didn't know about the possibility or didn't care to make use of it.)
Update: OTOH, it's easy to imagine situations in which the original name of a variable is gone beyond even the ability of PadWalker to access it. In the example below (don't try this at home: bug: dependence on execution order), the name of the lexical @ra array is, I believe, absolutely gone upon exit from the scope in which it is defined, but the data lives on as long as there is a reference to it.
>perl -wMstrict -le
"use Data::Dumper;
;;
{
my @ra = qw/ worker@company.com manager@company.com /;
sub AR { return \@ra; }
}
;;
my %services = (
service1 => { email => AR() },
service2 => { email => AR() },
);
;;
print Data::Dumper->Dump( [ \%services ], [qw/*services/] );
"
%services = (
'service1' => {
'email' => [
'worker@company.com',
'manager@company.com'
]
},
'service2' => {
'email' => $services{'service1'}{'email'
+}
}
);