<div dir="ltr"><br><br><div class="gmail_quote">On Wed, Jul 30, 2008 at 2:16 AM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2008/7/30 Colin Putney <<a href="mailto:cputney@wiresong.ca">cputney@wiresong.ca</a>>:<br>
<div><div></div><div class="Wj3C7c">><br>
> On 29-Jul-08, at 1:24 PM, Eliot Miranda wrote:<br>
><br>
>> BTW, immutability involves primitive error codes and I will be introducing<br>
>> primitive error codes, because the performance hit is essentially zero and<br>
>> there is no backward compatibility issue (strange but true :) ).<br>
><br>
> I'm all for general immutability support in the VM.<br>
><br>
> I suspect, though, that this isn't what Stéphane was driving at. Immutable<br>
> strings is kind of a language-level thing, and could be done without VM<br>
> support. One way would be to factor out a MutableString class and keep it<br>
> distinct from regular strings. Going further, we could just remove the<br>
> mutation protocol and require all string creation to be either stream-based<br>
> or functional (ie, producing new strings rather than mutating existing<br>
> ones).<br>
><br>
> Once strings are immutable, interning them is a useful space optimization,<br>
> and that *would* make symbols redundant.<br>
><br>
> Clearly there are huge compatibility issues here, but it's a reasonable<br>
> thing to consider if building a system from scratch.<br>
><br>
> Colin<br>
><br>
<br>
</div></div>+1<br>
i think we can live without immutable support from VM.<br>
Arrays and Strings can be subclassed with disabled mutation methods.<br>
And then compiler could use these classes for literals.<br>
Except from compiler support, where else we need immutability?<br>
Do we need a generic immutability , which would allow to flag any<br>
object from being changed?<br>
This is useful feature, but i doubt that alone, it could improve code<br>
quality or solve security issues so easily.</blockquote><div><br></div><div>No one is saying its a magic bullet. But it is an important element in code quality and security.</div><div><br></div><div>For one advantage, take a careful look at GemStone implementations in contexts where there is per-object immutability and where there isn't. GemStone's run-time is much simpler when there is per-object immutability support.</div>
<div><br></div><div>I'm curious why you're so against this. Do realise the modifications to the VM are pretty small and well-contained, and the performance overhead very small. Also realise that VW and VA do very well with it.</div>
</div></div>