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

And if it is immutable, I simply don't have to care. That's a benefit, because it reduces mental load while programming.

Sorry, but that simply isn't true. There is no reduction in cognitive load in a hybrid environment, because you still have to think about which type you are dealing with every time.

That's not a big issue if you have a clear mental model about what a "value object" and what a mutable object is.

A clear mental model huh.

Perl 5 is a good example: numbers are immutable,

Really?

$i = 1; ++$i; print $i;; 2

Okay. Bye.


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.
  • Comment on Re^8: The fallacy of the *requirement* for read-only instance variables.
  • Download Code

Replies are listed 'Best First'.
Re^9: The fallacy of the *requirement* for read-only instance variables.
by moritz (Cardinal) on Apr 18, 2011 at 11:26 UTC
    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.

      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.

        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;

        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

        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.

      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.

        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.