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

Marcel Taeumel marcel.taeumel at hpi.de
Wed Jun 5 07:18:33 UTC 2019


Hi Chris,

-1 for moving #join etc. up to Collection. You seem to favor some performance improvement over code readability. Making the order of the collection explicit before joining it feels more robust. #joinSeparatedBy: on non-sequencable collections has to much potential for bugs and unreadable code. See http://forum.world.st/The-Inbox-Collections-ct-827-mcz-tp5099876p5099964.html [http://forum.world.st/The-Inbox-Collections-ct-827-mcz-tp5099876p5099964.html] -- Having a non-seq. collection to join should not be a common case.

-1 for mixing up separate concerns in a single commit. Please, try separating those things.

Best,
Marcel
Am 05.06.2019 00:14:53 schrieb Chris Muller <asqueaker at gmail.com>:
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.

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

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190605/16fcd3ae/attachment.html>


More information about the Squeak-dev mailing list