<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-10-11 22:11 GMT+02:00 Jan Vrany <span dir="ltr"><<a href="mailto:jan.vrany@fit.cvut.cz" target="_blank">jan.vrany@fit.cvut.cz</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On Wed, 2017-10-11 at 22:01 +0200, Nicolas Cellier wrote:<br>
>  <br>
><br>
><br>
> 2017-10-11 21:56 GMT+02:00 Jan Vrany <<a href="mailto:jan.vrany@fit.cvut.cz">jan.vrany@fit.cvut.cz</a>>:<br>
> > On Wed, 2017-10-11 at 21:49 +0200, Bert Freudenberg wrote:<br>
> > >  <br>
> > > On Wed, Oct 11, 2017 at 9:32 PM, Jan Vrany <<a href="mailto:jan.vrany@fit.cvut.cz">jan.vrany@fit.cvut.cz</a><br>
> > ><br>
> > > wrote:<br>
> > > ><br>
> > > > > Indeed such feature is essential for live coding.  I will<br>
> > have to<br>
> > > > add<br>
> > > > > it to my implementation thanks.<br>
> > > ><br>
> > > > I don't think become: is essential. Smalltalk/X for instance<br>
> > does<br>
> > > > not<br>
> > > > use #become: yet it still provides live coding (in my opinion).<br>
> > ><br>
> > > Do you know how instances are reshaped without become in<br>
> > Smalltalk/X?<br>
> ><br>
> > Yes, it's very simple: they are not reshaped at all :-)<br>
> ><br>
> > Jan<br>
><br>
>  <br>
> Then does that mean that<br>
> - classes are not mutated, but that a new one is created, and old<br>
> objects are still pointing on old classes,<br>
<br>
</span>Exactly. The old class eventually becomes (not #become:s :-) garbage <br>
and gets (eventually) collected.<br>
<span class=""><br>
> - or that mutation is forbidden as long as instances or sub-instances<br>
> exist (like in Smalltalk V if I remember)<br>
> - or that one may expect catastrophic consequences when reshaping?<br>
<br>
</span>Depends what you call catastrophic consequences...<br>
<span class="HOEnZb"><font color="#888888"><br>
Jan<br>
</font></span></blockquote></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Catastrophic could be for example a buffer overflow that would bypass VM safety...</div><div class="gmail_extra">Typically when instances and compiled methods idea of inst. var. layout divorces.</div><div class="gmail_extra">That does not seem the case in Smalltalk/X from what you describe...<br></div><div class="gmail_extra">For example, in Squeak or VW, when there is a Foo>>bar method up in the stack that triggers removal of an ivar, then writes into an ivar, boom! object memory is corrupted... Indeed the methods cannot easily be become'd while still active... So they are replaced - but the instances are become'd<br></div></div>