On Sun, Aug 21, 2011 at 08:10:46PM -0400, Mark J. Reed wrote: > 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.
It wouldn't be fit to be called Perl if it defaulted to total immutability. > 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. Is it? If, at the implementation layer, all accesses to objects are actually function calls called via vtables, then surely it's *relatively* simple to change the vtable to replace * mutator methods with methods which croak (the shallow read-only part) * accessor methods for internal storage with methods which return proxy objects which are read-only ie there's no need to internally actually make defensive copies, or have some complex flag-checking system. It should be possible* to implement it in a small, incremental "obviously no bugs" fashion, instead of a monolithic, large "no obvious bugs" fashion.** Nicholas Clark * "should be possible" in that I've not tried this, because I know that it distinctly isn't possible in Perl 5, which is stuck in the centaury of direct structure access. ** but there will be bugs. Sadly.
