Why do the Perl developers (or others for that matter) consider it OK to change the internal respresentation of data (albeit the narrow context of Hash values) when it is referenced?
Well, to be fair, it's the internal representation. (BTW, it's not just hash values, scalars in general work this way.) All you see happening here is, as you said, Perl internally "caching" the results of its automatic and usually transparent conversion between strings and numbers - a major feature of the language. To a Perl programmer, 123 and "123" are (almost) always the same thing, and that's A Good Thing ;-)
I have just shown one case it matters!
Yes, one downside of the transparent conversion between strings and numbers inside Perl is that libraries that convert from Perl's data format to another have this issue to overcome (Data::Dumper, Data::Dump, the various JSON modules, ...). Some choose to always output it in one format, others use heuristics to decide whether something looks like a string or a number, and yet others try to look at Perl's internal representation, which as you've seen can change very easily. All of these ways have their flaws.
References:
In Perl, figuring out the difference between 42 and "42" is nontrivial (and luckily, a Perl programmer usually doesn't have to care). If the consumer of Perl's output does happen to care, it's usually best to have some way to explicitly output one or the other.
In reply to Re^3: Hash value typing
by haukex
in thread Hash value typing
by waynerasm
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |