<br><br><div class="gmail_quote">On Thu, Jun 14, 2012 at 12:14 PM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com" target="_blank">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">
<div class="im"><br>
On 14 June 2012 20:31, Colin Putney <<a href="mailto:colin@wiresong.com">colin@wiresong.com</a>> wrote:<br>
><br>
> Igor wrote:<br>
><br>
>> In theory, of course we can enforce anything, but in practice that<br>
>> means a lot of complex code with many checks at VM side.. This is not<br>
>> what i like to see in a first place, especially knowing that Squeak<br>
>> lived well so far without any immutability and it does not feels like<br>
>> we miss it badly.<br>
><br>
> Andreas responded:<br>
><br>
>> I absolutely do. There were several situations (for example in Croquet<br>
>> and at Teleplace) where we changed our designs to the worse merely due<br>
>> to the lack of immutability support. The main thing that immutability<br>
>> fixes is to prevent accidental modifications of objects thought to be<br>
>> immutable (method literals for example), which when they happen are<br>
>> *extremely* hard to find. But it also gives rise to many other<br>
>> interesting techniques (read-only transactions etc).<br>
><br>
> I have to agree with Andreas here. I've used immutability to good<br>
> effect in VisualWorks, and run into several situations where I wanted<br>
> it in Squeak and had to make do with a work around. Avi's WriteBarrier<br>
> package is one of those workarounds.<br>
><br>
> To be honest, I'm a little puzzled by the resistance to immutability.<br>
<br>
</div>Well, my main take against it, that smalltalk lived quite well without<br>
it so far.<br></blockquote><div><br></div><div>But it *hasn't*, as evinced by the bugs in the base libraries surfaced by adding immutablity to VisualWorks (and no doubt to VisualAge as well).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If it would be so crucial, then it would be there long ago, (even back<br>
in ST'80) isn't?<br></blockquote><div><br></div><div>On a 16-bit machine with 32k objects there were many things that were lived without. Would you have us do without ensure: and exceptions and tuples and closures just because Smalltalk-80 didn't have them? What a silly argument.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
>From a purist's perspective, it also doesn't looks like a good move.<br>
Because originally we start from quite simple and universal:<br>
- everything is an object<br>
then we added<br>
- all objects are instances of some class<br>
<br>
but now we adding:<br>
all objects *also* have identity hash<br>
all objects *also* have immutability bit<br>
<br>
today we have few of those *also's* , tomorrow we will find the need<br>
for 50 more, because there's virtually<br>
no limit about what additional properties we may want to have per object..<br>
<br>
And so, an only logical step, as to me was to do it for real:<br>
I proposed to add a slot for arbitrary properties per object, is<br>
simply a unification of the above,<br>
so you can state:<br>
- all objects *also* have at least one property slot, which can be<br>
used by language to store arbitrary properties per object (or at least<br>
one), *without* a need from object in question to have a direct<br>
knowledge<br>
about the nature of these properties (in contrast to instance<br>
variables, immutability, hash etc).<br>
<br>
That also means that VM don't needs to know anything about those<br>
properties as well, which directly converts into less code and less<br>
complexity.<br>
<div class="im"><br>
<br>
> It's not like this is a new idea with unclear semantics or unknown<br>
> utility. The VisualWorks implementation is simple and useful.<br>
> VisualWorks is still the fastest Smalltalk around, so the performance<br>
> impact can't be *too* high. VisualWorks is fairly similar to Squeak,<br>
> so it's not unreasonable to use it as a model for considering<br>
> immutability in Squeak.<br>
><br>
> Now, maybe there really are problems with the VW, VA or Gemstone<br>
> implementations, and if so, let's hear about them. "It's not<br>
> necessary" isn't a good argument, because nothing is really<br>
> necessary—assembly works fine. What are the costs, benefits and<br>
> trade-offs of VM-supported immutability?<br>
><br>
<br>
</div>For me the main cost is, of course, performance. If we take our<br>
existing images (which have no notion<br>
about immutability) they will perform slower on same hardware.<br>
We can turn this cons into pros, only when we will start using<br>
immutability around the places..<br>
and here is where fun stuff begins: you cannot manage immutability<br>
state over more than ONE framework.<br>
So you will have to invent more complex schemes like mentioned<br>
"immutability managers" etc..<br>
<br>
Anyways, the fact is, that most software will still won't use it<br>
anyways, but you will keep paying the price of having it.<br>
It's like introducing a new tax "to fund an activities to keep<br>
homeowner's lawns green and clean", and taking it from everyone, even<br>
from those who don't have own lawn and even don't own the house :)<br>
<br>
<br>
> Colin<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
--<br>
Best regards,<br>
Igor Stasenko.<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div><br>