<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 5 juin 2019 à 22:50, Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">>> > 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>
> The number of senders does not matter.<br>
> What is important is that it's programmer responsibility to make sure that this strings won't be mutated (become'd).<br>
><br>
> Until we protect our literals...<br>
<br>
Fair enough.  I respect your argument.<br>
<br>
>> > 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: '',<br>
>> but with #empty<br>
>> being an integrated part of the API, it's the intent as everywhere<br>
>> else it's used.<br>
>><br>
>><br>
> I would be very surprised if you could measure any difference between String new and String empty in this specific case.<br>
<br>
Yes, especially since we're talking about making a collection of<br>
subStrings: anyway...   :)<br>
<br>
I'm convinced.<br>
<br>
>> > 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>
> It does not necessarily.<br>
> For example in Xtreams, you'll see this method:<br>
><br>
> XTSequenceableCollection>>close<br>
>      position < destination size ifTrue: [destination := destination copyFrom: 1 to: (position min: length)]<br>
><br>
> The copy is omitted if unnecessary.<br>
<br>
How does XTSequenceableCollection>>#close from an external package<br>
relate to use of a temporary WriteStream inside the method,<br>
String>>#subStrings:?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">If instead of explicitly allocating new substring target, we decide to reuse a recipient for optimization purpose, we then depend on implementation details, like assuming that contents does always copy.</div><div dir="auto"><br></div><div dir="auto">Xtreams illustrates that such details may vary from one stream implementation to another. As an alternate stream implementation based on composition rather than inheritance, Xtreams has been seriously considered as a potential Stream replacement, at least in Pharo, so it's kind of Stream refactoring that may happen.</div><div dir="auto"><br><span style="font-family:sans-serif">If we authorize ourself to omit a copy at one place (substrings) we might as well do it at a more general place (contents) for same reasons...</span><br></div><div dir="auto"><span style="font-family:sans-serif"><br></span></div><div dir="auto">We can also take such implementation details as granted and consider that they are part of the contract. The longer the contracts, the greater the chance to break the contract when we want to evolve/refactor the features. That's often the price we pay for optimizing...</div><div dir="auto"><br></div><div dir="auto">I'm ok with those design decisions if it really makes a measurable difference, but we might better add tests to make the contract explicit.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> I think that VW version additionally use destination become: (but I do not have a copy handy)<br>
> We can consider that contents always copy as part of the contract.<br>
> It's a matter of depending on very short contract, or long and detailed contract.<br>
> Classical price of optimization...<br>
><br>
><br>
><br>
<br>
</blockquote></div></div></div>