[squeak-dev] The Inbox: Collections-cmm.836.mcz

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed Jun 5 16:48:56 UTC 2019

Le mer. 5 juin 2019 à 00:14, Chris Muller <asqueaker at gmail.com> a écrit :

> Hi Nicolas,
> > 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...

> 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.
Performance-wise, we could also pre-allocate some capacity (String new:
Knowing that some implementation did/might use a become, String empty is
not future proof
(if it has many senders, then it's even worse, once the literal mutated,
many senders will miss-behave)

> 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:

     position < destination size ifTrue: [destination := destination
copyFrom: 1 to: (position min: length)]

The copy is omitted if unnecessary.
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
Classical price of optimization...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190605/87ebce01/attachment.html>

More information about the Squeak-dev mailing list