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

Your example only shows that variables that contain numbers are mutable. But since you can't do 3 = 5;, or modify the number 3 in any other way, numbers are immutable.

Now you might say that's obvious and not worth discussing, but it does show that not everything is mutable. You can only say that everything is mutable for very limited definitions of "everything", which currently suit your needs.

Perl 6 - second systems done right

Replies are listed 'Best First'.
Re^10: The fallacy of the *requirement* for read-only instance variables.
by JavaFan (Canon) on Apr 18, 2011 at 12:25 UTC
    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.
[reply]
[d/l]
[select]

      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]
Re^10: The fallacy of the *requirement* for read-only instance variables.
by BrowserUk (Patriarch) on Apr 18, 2011 at 11:57 UTC
    Now you might say that's obvious and not worth discussing,

    Yes. But not just obvious. Meaningless. Of absolutely no practical, nor even theoretical, value whatsoever.

    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]

      Oh really? I find it very practical that my number literals are immutable.

      In Java strings are immutable, but you can still assing a new String to a String-typed variable. Perl follows the exact same model for numbers. Why is this suddenly meaningless, but not in the Java case? You might say because you can think of mutable strings but not of mutable numbers, but that's just a limit of your imagination.

      Also declaring something that contradicts your line of thought as "meaningless" without any explanation isn't very good style of discussion.

      Perl 6 - second systems done right
[reply]
        Perl follows the exact same model for numbers.

        No, it doesn't. As I demonstrated above, variables holdiing numeric values are **NOT** immutable. Constants are (to use your own word) obviously immutable. But variables are not constants. And variables are not immutable.

        Also declaring something that contradicts your line of thought as "meaningless" without any explanation isn't very good style of discussion.

        No explanation is necessary. You already demonstrated above that you know this is nothing more than an obvious non sequitur to the threads subject. Hence, further discussion is meaningless and pointless.

        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]

In Section Meditations