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

If it isn't and you are concerned, then you can pass in a copy.

If it is, and you don't want that, you could pass in a copy.

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

You're right. That was badly phrased and I apologise.

Apolgy accepted.

What you are implying, knowingly or not, is that every object should be immutable.

Not at all. There's a trade-off.

Because the alternative is a hybrid of mutable and immutable objects, that creates far more risk of forgetting to pass a copy when you need to ensure the original remains unmodified; or unnecessarily copying for the same reason.

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

Again you're trying to argue that there's not sensible middle-ground, and I disagree.

I know of no language where everything is mutable, nor do I know languages where everything is immutable (in Haskell monads give you access to mutable storage).

Perl 5 is a good example: numbers are immutable, strings are not. That's a sensible tradeoff, but that doesn't mean there can't be other sensible tradeoffs.

Perl 6 - second systems done right
  • Comment on Re^7: The fallacy of the *requirement* for read-only instance variables.

Replies are listed 'Best First'.
Re^8: The fallacy of the *requirement* for read-only instance variables.
by BrowserUk (Patriarch) on Apr 18, 2011 at 10:30 UTC
    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

    [download]

    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.
[reply]
[d/l]
      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
[reply]
[d/l]
[select]
        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]
        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]
Re^8: The fallacy of the *requirement* for read-only instance variables.
by John M. Dlugosz (Monsignor) on Apr 22, 2011 at 09:17 UTC
    In C++, I can declare a date that can be mutated, or a const date which is immutable. And I can convert the first to the second, or copy the second into the first.
[reply]

In Section Meditations