2008/7/30 Eliot Miranda <eliot.miranda at gmail.com>:
>
>
> 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.
>
>

Agreed, OODBs could use an immutability bit for own purposes - like
putting a write barrier on objects and then handle objects mutation to
track their changes during transaction.
I never worked with GemStone, but have some experience with Magma, and
its using a 'hacky' way by changing an object's class to put a write
barrier on objects.
So, it is possible to do the same without immutable bit. And also, it
is more precise , because there can be many reasons why you get a
NoModificationError (it can be a simple programming error) , while if
you catching it with write barrier - you definitely know that it is
what you expected and can deal with it properly.

And if system allows marking object back to be mutable? Then how you
could really tell that particular object is never modified during its
lifetime?
I think it should be sealed by behavior, by preventing any methods,
which can modify an instance, to appear in class. So, the only real
thing which can guarantee that given object remain unchanged during
its lifetime is a class. An immutability bit is much worse thing
comparing to this.

And second, its against the spirit of smalltalk. Smalltalk is one of
the languages, where it tries to implement all things through
behavior, not through using different VM/language magic intrinsics.
It is not a problem, what VM having or not having an immutablity bit,
its a problem, that current kernel classes and/or collections designed
without looking at possible use cases where user wants to prevent
object from being changed during its lifetime.
So, maybe we should think how to refactor these classes instead of
including one more magic thing?

-- 
Best regards,
Igor Stasenko AKA sig.