Beefy Boxes and Bandwidth Generously Provided by pair Networks Cowboy Neal with Hat
Do you know where your variables are?
 
PerlMonks  

Re: Why do $x="$h->{foo}" and $x=$h->{foo} have different effects (as reported by Devel::Peek)?

by borisz (Canon)
on Mar 25, 2009 at 16:52 UTC ( #753177=note: print w/ replies, xml ) Need Help??


in reply to Why do $x="$h->{foo}" and $x=$h->{foo} have different effects (as reported by Devel::Peek)?

You use $x as number and sometimes as string. When you use it as number, IV holds the value and PV is updated on demand. Thats all.

Boris


Comment on Re: Why do $x="$h->{foo}" and $x=$h->{foo} have different effects (as reported by Devel::Peek)?
Re^2: Why do $x="$h->{foo}" and $x=$h->{foo} have different effects (as reported by Devel::Peek)?
by ELISHEVA (Prior) on Mar 25, 2009 at 17:19 UTC

    Many thanks - I hadn't realized that PV was updated "just-in-time".

    But why doesn't this confuse Perl? After experimenting a bit, it seems that when IV and PV have different values, Perl always knows which one to trust - is it one of the flags? (Update: yes - see kyle's and ikegami's posts below)

    On the other hand, Storable seems to blindly favor PV when both IV and PV exist, even if they are in conflict. Is this a bug in Storable (v. 2.15)? Should it be doing what Perl does, but isn't?

    Best, beth

    Update:After further experimentation it appears that Storable does dump the correct value but its choice of binary representation for that value seems to be affected by the flags at the time of freezing. Thus an IV only variable (only IOK,pIOK flags set) freezes to a different string than a variable where both PV and IV are set (IOK,pIOK,POK,pPOK flags set). This is true even though both would stringify to the same Perl string (e.g. 5 => "5") and both would appear to be equal (in Perl) when thawed. That is, $x1 eq $x2, $x1 == $x2 would both be valid and true, even in strict mode.

      But why doesn't this confuse Perl?

      Using the output of your first snippet as an example,

      SV = PVIV(0x8150b10) at 0x814f6b4 <-- Can contain an IV and PV REFCNT = 1 FLAGS = (IOK,pIOK) <-- Only contains an IV IV = 123 PV = 0x81623f0 "abc"\0 CUR = 3 LEN = 4 SV = PVIV(0x8150b10) at 0x814f6b4 <-- Can contain an IV and PV REFCNT = 1 FLAGS = (POK,pPOK) <-- Only contains a PV IV = 123 PV = 0x81623f0 "123"\0 CUR = 3 LEN = 4

      The type of the scalar is promoted as necessary. Downgrading would be a waste of time, so flags are used to indicate what kind of value the scalar contains.

      Note that it's possible to have a scalar that has both an IV and PV.

      $ perl -MDevel::Peek -e'$x = 123; Dump $x; "$x"; Dump $x' SV = IV(0x816a41c) at 0x814f69c REFCNT = 1 FLAGS = (IOK,pIOK) <-- Only contains an IV IV = 123 SV = PVIV(0x8150b10) at 0x814f69c REFCNT = 1 FLAGS = (IOK,POK,pIOK,pPOK) <-- Stringification has IV = 123 been cached. PV = 0x81651a0 "123"\0 CUR = 3 LEN = 4

      On the other hand, Storable seems to blindly favor PV when both IV and PV exist,

      When both IV and PV exist (i.e. when the scalar is a PVIV or subtype), or when POK is set? The former would definitely be a bug. Otherwise, read on.

      If a scalar contains both a number and a string (POK and either IOK or NOK), the situation is intended to be one of the following (and almost always is):

      • The string is a stringification of the IV.
      • The string is a stringification of the NV.
      • The number is a numification of the string.

      If we accept that more general dualvars can't be stored, we should be able to store only one of the string or the number. So which one should we used when?

      The string is a stringification of the IV.

      Stringification of IVs is lossless, and so is their numification.

      Either the string or the IV will do.
      The string is a stringification of the NV. Stringification of NVs is practically lossless, and so is their numification. Either the string or the NV will do.

      The number is a numification of the string.

      Numification of non-numeric strings is lossy. e.g 0+"abc" ne "abc".

      Numification of partially numeric strings is lossy. e.g 0+"123abc" ne "123abc".

      Numification of some numeric strings is lossy. e.g 0+"0.50" ne "0.50".

      Necessarily, we need to store the string.

      As such, always storing the string is sufficient and appropriate.

      Update: Storing the string instead of the number also allows us to store '0 but true' and '0E0', true values that evaluate to zero.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://753177]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (8)
As of 2014-04-19 13:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (480 votes), past polls