Patrick R. Michaud wrote:
On Sat, Aug 20, 2011 at 04:41:08PM -0700, Darren Duncan wrote:
I believe the general solution to this problem is to make all
objects immutable, with the only exception being explicit
references, and so mutating an object isn't an option; rather you
have to derive a new object.
"Values" of all types should be immutable, even if that type is
Array or whatever, and only "Variables" should be mutable.
...
To make sure I understand correctly, you're essentially
saying that @a.push(3) should not modify @a directly -- someone
would have to write something like
@a = @a.push(3) # or @a .= push(3)
And to do a "shift", one would have to do something like
($value, @a) = @a;
since @a.shift would be unable to mutate the array. (I'm not
exactly sure what pop would look like.)
Is that correct?
Yes, that's what I'm saying.
And we've already been making moves in that direction.
As I recall, regular expression substitutions were already changed to work that
way, returning the modified string rather than modifying the argument, so there
is precedent.
Moreover, thanks to meta-operators, one can typically get a mutating variant of
any otherwise non-mutating operator very tersely with just a single added "="
character.
This aids learnability as there's a relatively simple mnemonic, where nearly any
given operator foo is non-mutating, but by adding an "=" to it you get a
mutating variant, so people can look for the "=" to know if it would mutate.
The comparison ops are the rare exception to the rule.
-- Darren Duncan
