>> > I don't much like WriteStream on: String empty.
>> > 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...
>>
>> We both know that's not going to happen.  #empty has been a class-side
>> constructor/accessor on several classes for a long time, with > 100
>> senders in trunk alone.  It's an integrated part of the
>> class-library's API which improves performance and readability.  Any
>> attempt to switch back to a become implementation for growing internal
>> collections would spoil that API everywhere.
>>
> The number of senders does not matter.
> What is important is that it's programmer responsibility to make sure that this strings won't be mutated (become'd).
>
> Until we protect our literals...

Fair enough.  I respect your argument.

>> > String new better express our intention, we want a new substring.
>>
>> But sometimes we trade intention-revealingness for performance.
>> That's what this is.
>>
>> I would offer the compromise of WriteStream on: '',
>> but with #empty
>> being an integrated part of the API, it's the intent as everywhere
>> else it's used.
>>
>>
> I would be very surprised if you could measure any difference between String new and String empty in this specific case.

Yes, especially since we're talking about making a collection of
subStrings: anyway...   :)

I'm convinced.

>> > Also, contents does not necessarily answer a copy,
>>
>> But it does.  WriteStream>>#contents answers a #copyFrom:to: and even
>> the comment says "Answer with a copy ..."
>>
>>  - Chris
>>
> It does not necessarily.
> For example in Xtreams, you'll see this method:
>
> XTSequenceableCollection>>close
>      position < destination size ifTrue: [destination := destination copyFrom: 1 to: (position min: length)]
>
> The copy is omitted if unnecessary.

How does XTSequenceableCollection>>#close from an external package
relate to use of a temporary WriteStream inside the method,
String>>#subStrings:?


> I think that VW version additionally use destination become: (but I do not have a copy handy)
> We can consider that contents always copy as part of the contract.
> It's a matter of depending on very short contract, or long and detailed contract.
> Classical price of optimization...
>
>
>