in reply to Re: Hash value typing
in thread Hash value typing

Thank you!
Now that just leaves me with one more question? 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? i.e from one reference to another Devel::Peek may (because it depends on the context of the reference) give you different results without you ever having consciously changed the data itself! My guess is that, by way of my example, once the conversion of 1 from binary (32|64 bit integer) to character "1" happens (such as the length function would trigger) someone decided it was likely to happen again so save a few cycles and replace the binary with the character string - nobody's looking or will know right - however, I have just shown one case it matters!
Again thanks. As the wise old doctor said when told "Doctor when I do this it hurts!", the reply "Then don't do that!". Sort of like '\' looks reasonable but it doesn't do what you(well more specifically I) expect(before the pain reminds me not to do that)!

Replies are listed 'Best First'.
Re^3: Hash value typing
by shmem (Chancellor) on Jun 10, 2018 at 16:05 UTC
    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?

    Because that's what loose typing is all about - and perl works that way, sorry. In your example, you did not reference/dereference anything, but coerced the numeric value to a string, by treating it as a string (taking the length from it). Instead of creating a temporary variable as a typecast copy of the number value, perl stores that string value in the PV slot of the variable. The NV (numeric value) and/or IV (integer value) slots of the variables remain unaffected.

    Apparently, for the JSON::XS code the PV slot has priority over the NV and IV slots. If you want numbers to remain numbers in your JSON output, you would need to inspect the values and numify them, e.g. 

    #!/usr/bin/perl
%x=(a=>1);
print length($x{a}),"~",
  encode_json(
    {
      map {
        $_ => $x{$_} =~ /^[\d.]+$/ ? 0+$x{$_} : $_
      } keys %x
    }
  ),"\n";
__END__
1~{"a":1}

    [download]
    perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
[reply]
[d/l]

      BUG->no, lack of understanding on my part->yes (at least 'was' until you kindly helped remedy that), feature->jury's out.
      Thank you for the insight and a means (code) to address the impetus for the seeking of the 'light' in the first place!

[reply]
Re^3: Hash value typing
by haukex (Archbishop) on Jun 10, 2018 at 22:24 UTC
    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.

[reply]
[d/l]
[select]

      BUG->no, lack of understanding on my part->yes (at least 'was' until you kindly remedied that)
      Thank you

[reply]

In Section Seekers of Perl Wisdom