On Fri, 9 Sep 2011, Carl Mäsak wrote: > Patrick Michaud said something (I think AFK) that seems essential to > me: the non-rw-ness of these objects isn't a trait of *the object > itself*, it's a trait of *the context in which the object is used*.
In one sense that is true, but if that's the only kind of constancy that gets implemented, then it's only half the story. It is of course useful to be able to send a "value" to a sub and know that it won't be mangled when the sub returns, and you do get that from the "const reference" approach that's implied by Patrick's comment. But it's also useful, when in the sub, to know that the someone else won't mess with a "value" while you're working with it. I can't see any way to enforce that without constancy being a feature of the object rather than the reference to it. Moritz Lenz wrote: > I think we should consider the implications of > immutability-all-the-way-down before we jump to any conclusions. In > particular list cases where typical Perl 5 code fails when ported to Perl > 6. Perhaps if we could tag the type/class/pmc/whatever when it's constructed as to whether it defaults to r/o or r/w? Hence things like file handles would be r/w by default, and most other things would be r/o. Actually, I'm inclined to think that r/o vs r/w for sub params is a bit of a blunt instrument. What about the option of treating a "r/w" param as a shorthand for both an r/o param AND an r/o return? So in effect, changes to the "container" don't take effect until after the sub returns. (BTW this would have a lot of benefits for auto-threading code.) -Martin
