On Wed, Jul 30, 2008 at 2:16 AM, Igor Stasenko <siguctua at gmail.com> wrote:

> 2008/7/30 Colin Putney <cputney at wiresong.ca>:
> >
> > On 29-Jul-08, at 1:24 PM, Eliot Miranda wrote:
> >
> >> BTW, immutability involves primitive error codes and I will be
> introducing
> >> primitive error codes, because the performance hit is essentially zero
> and
> >> there is no backward compatibility issue (strange but true :) ).
> >
> > I'm all for general immutability support in the VM.
> >
> > I suspect, though, that this isn't what Stéphane was driving at.
> Immutable
> > strings is kind of a language-level thing, and could be done without VM
> > support.  One way would be to factor out a MutableString class and keep
> it
> > distinct from regular strings. Going further, we could just remove the
> > mutation protocol and require all string creation to be either
> stream-based
> > or functional (ie, producing new strings rather than mutating existing
> > ones).
> >
> > Once strings are immutable, interning them is a useful space
> optimization,
> > and that *would* make symbols redundant.
> >
> > Clearly there are huge compatibility issues here, but it's a reasonable
> > thing to consider if building a system from scratch.
> >
> > Colin
> >
>
> +1
> i think we can live without immutable support from VM.
> Arrays and Strings can be subclassed with disabled mutation methods.
> And then compiler could use these classes for literals.
> Except from compiler support, where else we need immutability?
> Do we need a generic immutability , which would allow to flag any
> object from being changed?
> This is useful feature, but i doubt that alone, it could improve code
> quality or solve security issues so easily.


No one is saying its a magic bullet.  But it is an important element in code
quality and security.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080730/dfc8cba3/attachment.htm