Hi Chris,

a good exercise would be to read unfamiliar code on a regular basis. Unfortunately, there not many hard, objective metrics to asses readability. So, there are mostly opinions and customs. As a consequence, my argument for readability cannot be flawed in a general sense. ;-)

Here is another summary of my thoughts:

- #joinSeparatedBy: concatenates elements in collections of some stable order.
- For other collections, a debugger would appear showing MNU.
- The programmer can now notice and asses the unstable order of that collection.
- The programmer can then choose to change the kind of collection (1) somwhere meaningful in the program or (2) directly before that join operation to make some order explicit.

If it is just for debugging, an extra #asArray wouldn't hurt. If it is for production code, such inadvertent instability of collection order can make the live unnecessarily hard.

Of course, Chris, you can read this as just another opinion of mine. You can also try to explain your two points somehow: (1) How big is that performance impact in your daily code? (2) Why don't you like the idea of making stable order in a collection more explicit somewhere in the code?

Best,
Marcel
Am 05.06.2019 23:40:22 schrieb Chris Muller <asqueaker at gmail.com>:
Hi Marcel,

You're free to write your code the way you feel you need to, but I
hope going forward you'll allow others to do the same. Even if your
readability argument wasn't so flawed, trying to force others to write
what you think is good code is utterly futile.

I'll keep it in Collection in my Base package for now. Just so you
know, it IS a common case to need it for non-seq collections -- it's
how this whole discussion got started, remember?

- 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 -- 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 :
>
> 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/20190606/e54db9fb/attachment.html>