<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 5 juin 2019 à 00:14, Chris Muller <<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Nicolas,<br>
<br>
> I don't much like WriteStream on: String empty.<br>
> If String empty is implemented as answering a literal, and WritStream implemented to become the grown contents as it originally did in st80 and could also do in Squeak now that we have a fast become, we take the risk to modify the literal...<br>
<br>
We both know that's not going to happen.  #empty has been a class-side<br>
constructor/accessor on several classes for a long time, with > 100<br>
senders in trunk alone.  It's an integrated part of the<br>
class-library's API which improves performance and readability.  Any<br>
attempt to switch back to a become implementation for growing internal<br>
collections would spoil that API everywhere.<br>
<br></blockquote><div>The number of senders does not matter.</div><div>What is important is that it's programmer responsibility to make sure that this strings won't be mutated (become'd).</div><div>Until we protect our literals...<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> String new better express our intention, we want a new substring.<br>
<br>
But sometimes we trade intention-revealingness for performance.<br>
That's what this is.<br>
<br>
I would offer the compromise of WriteStream on: '', but with #empty<br>
being an integrated part of the API, it's the intent as everywhere<br>
else it's used.<br>

<div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br></div>

</blockquote><div>
I would be very surprised if you could measure any difference between String new and String empty in this specific case.

</div><div>Performance-wise, we could also pre-allocate some capacity (String new: someHeuristiceSize).</div><div>Knowing that some implementation did/might use a become, String empty is not future proof</div><div>(if it has many senders, then it's even worse, once the literal mutated, many senders will miss-behave)<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Also, contents does not necessarily answer a copy,<br>
<br>
But it does.  WriteStream>>#contents answers a #copyFrom:to: and even<br>
the comment says "Answer with a copy ..."<br>
<br>
 - Chris<br>
<br></blockquote><div>It does not necessarily.</div><div>For example in Xtreams, you'll see this method:</div><div><br></div><div>XTSequenceableCollection>>close<br>           position < destination size ifTrue: [destination := destination copyFrom: 1 to: (position min: length)]</div><div><br></div><div>The copy is omitted if unnecessary.</div><div>I think that VW version additionally use destination become: (but I do not have a copy handy)<br></div><div>We can consider that contents always copy as part of the contract.</div><div>It's a matter of depending on very short contract, or long and detailed contract.</div><div>Classical price of optimization...<br></div><div><br></div><div><br></div></div></div>