<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2014-03-25 21:41 GMT+01:00 Tobias Pape <span dir="ltr">&lt;<a href="mailto:Das.Linux@gmx.de" target="_blank">Das.Linux@gmx.de</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On 25.03.2014, at 21:07, Nicolas Cellier &lt;<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>&gt; wrote:<br>
<br>
&gt; OK, I see this works anyway because ByteString&gt;&gt;at:put: will handle the case and use becomeForward:<br>
&gt;<br>
&gt; But should we rely on this expectation? It comes from a Smalltalk where become: were cheap.<br>
&gt; For example, WriteStream&gt;&gt;pastEndPut: does not preserve collection identity<br>
&gt;<br>
<br>
</div>People rely on this :)<br>
I actually only got there because a Seaside test failed that made this expectation.<br>
<br>
Speaking about expectations.<br>
<br>
When I have an A, and I say<br>
<br>
&nbsp; &nbsp; &nbsp; &nbsp; WriteStream on: A<br>
<br>
I actually expect the stream to be &ldquo;on&rdquo; A.<br>
Become would be ok with me, because the new thing would<br>
be A still, but the collection replacement that happened<br>
up until now would not qualify any longer to be &ldquo;on A&rdquo;.<br>
<br>
Regarding #pastEndPut:, yes this is debatable, but sending<br>
#pastEndPut: clearly shows that the caller is aware that<br>
the put thing would end up beyond our beloved A. Which makes<br>
this a mere exceptional behavior (not in general but in regard<br>
to the &ldquo;on A&rdquo; expectation). It&rsquo;s a &ldquo;here be dragons&rdquo; situation for<br>
me, so anything&trade; could happen.<br>
<br>
Best<br>
<span class="HOEnZb"><font color="#888888">&nbsp; &nbsp; &nbsp; &nbsp; -Tobias<br>
</font></span><br><br></blockquote><div><br></div><div>Bah, Spur become might become cheaper soon anyway... So expectating preservation of identity after the most insane mutations might feel less silly next year (as long as you don&#39;t come from haskell or another functional language).<br>
</div><div>VW Xtreams implementation did rely on it, even in case of growth...<br></div></div><br></div></div>