The whole point of objects is to encapsulate state, accepting messages which operate and report on that state. Making a new object every time the state changes sort of defeats the purpose; I certainly wouldn't call it "object orientation done right".
Total immutability is very powerful, but it's not the way Perl 6 is designed, and would represent a radical departure in that design. However, I do think that we need selective immutability. I firmly agree in principle that "readonly all the way down" should just work, without the programmer having to jump through hoops to make defensive copies. Of course, the plumbing to make that happen strikes me as likely to be complex and therefore fragile. On Sun, Aug 21, 2011 at 12:00 AM, Darren Duncan <dar...@darrenduncan.net> wrote: > 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 > -- Mark J. Reed <markjr...@gmail.com>
