in reply to Re^9: The fallacy of the *requirement* for read-only instance variables.
in thread The fallacy of the *requirement* for read-only instance variables.

But since you can't do 3 = 5;, or modify the number 3 in any other way, numbers are immutable.
By the same logic, strings are immutable. "3" = "5"; is as immutable as 3 = 5;. I will buy both both strings and number are immutable and both strings and numbers are mutable (the former when talking about literals - the latter when talking about values of variables). But I won't accept your original statement numbers are immutable, strings are not - at least not until you have some reasoning that convinces me.

Replies are listed 'Best First'.
Re^11: The fallacy of the *requirement* for read-only instance variables.
by moritz (Cardinal) on Apr 18, 2011 at 12:44 UTC

    Strings mostly act as if they were immutable in Perl 5, so my statement should be taken with care. It's only when you look at the XS or C layer that you see mutable strings: 

    use Devel::Peek;

my $x = "foo";

Dump $x;
vec($x, 0, 2) = 3;
Dump $x;

    [download]

    Output: 

    SV = PV(0x1b6a088) at 0x1b8b340
  REFCNT = 1
  FLAGS = (PADMY,POK,pPOK)
  PV = 0x1b7a9a0 "foo"\0
  CUR = 3
  LEN = 8
SV = PV(0x1b6a088) at 0x1b8b340
  REFCNT = 2
  FLAGS = (PADMY,POK,pPOK)
  PV = 0x1b7a9a0 "goo"\0
  CUR = 3
  LEN = 8

    [download]

    You see two different strings at the same memory location, indicating mutability. Though it could of course be a newly allocated copy of the string, while the old one is gone.

    Maybe it would have been better if I had talked about hashes being mutable and numbers being immutable.

    My main point remains: Perl has some mutable and some immutable data types, and that all languages I know have that distinction too. So a line must be drawn, and in some contexts it might sense to create immutable objects.

    Perl 6 - second systems done right
[reply]
[d/l]
[select]
      Ah, so, number are immutable because the literals are, and string are mutable because variables holding the strings are.

      Right.

      Maybe it would have been better if I had talked about hashes being mutable and numbers being immutable.
      Same problem.

      You're only able to modify a hash by stuffing it into a variable - but once you do that, numbers are mutable as well.

      Anything that can appear on the LHS of an assignment is mutable (although the reverse doesn't automatically follow). Now, one can argue that there are no hash literals (they're either lists, or hashrefs), but that invalidate my arguments.

[reply]
      numbers being immutable.

      Same address, different value. In Perl, numeric variables are mutable. 

      C:\test>perl -MDevel::Peek -E"my $x = 12345; Dump $x; $x ^= 1; Dump $x
+"
SV = IV(0x2174e0) at 0x2174e8
  REFCNT = 1
  FLAGS = (PADMY,IOK,pIOK)
  IV = 12345
SV = IV(0x2174e0) at 0x2174e8
  REFCNT = 1
  FLAGS = (PADMY,IOK,pIOK)
  IV = 12344

      [download]
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]

In Section Meditations