Hi Marcel,

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

Nor can it be valid, for the same reason.  But that's not the flaw I
was referring to.

Here's why I will keep #joinSeparatedBy: on Collection:

    https://graphql.github.io/graphql-spec/June2018/#ImplementsInterfaces

That spec says the list of interfaces of an ObjectTypeDefinition are
joined and separated by '&'.  But the order doesn't matter, especially
to machines, which is the actor I'm printing for.

So, for this general utility method to impose an order in sender
contexts that absolutely /do not care/ becomes an unnecessary
conversion that imposes an unnecessary cost, including even in
readability.  Being meaningless in that context, so it's easy to
imagine it tripping up future readers forever,

    "why do we need this #asArray here?"

What would the answer to that question be?  What should it be?

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

A strange use of the word "unstable" here.   They're simply unordered,
Marcel.  We both know UnorderedCollections are common in many designs.

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

You keep saying, "The programmer can...," but that's not the issue
being argued, is it?  The argument is about unnecessarily "forcing"
the programmer into doing a conversion they don't want.

> a good exercise would be to read unfamiliar code on a regular basis.

Best,
  Chris


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