Here is my 100% personal opinion:

I don't like the copyShuffle.

To me, the rules are quite clear:

sort shuffle reverse etc... -> perform modification in place

sorted shuffled reversed etc... -> answer a copy

I hope the methods comments are clear. Does PBE tells about these conventions? It would be a good thing.

And I don't like to have mutexes in base library, the less we have, the better.

If a user is going to modify the same object concurrently, he/she takes care of mutual exclusion.

2013/9/23 Max Leske <maxleske@gmail.com>

Sven suggested posting this on the list for discussion, so here you go:

Maybe this should be discussed on the list, your are going to break API.

Note that there is also #sort and #sorted with similar copy behavior.

Also, I am not sure that basic operations should use mutexes to protect themselves by default: there is a cost when you are a single threaded user. Even in Java there are synchronized and non-synchronized versions of collections. IMHO, the protection should happen in your app, and basic collections do not have to be thread safe.

Sven

#shuffle does not use Collection>>mutexForPicking as other users of #randomForPicking demonstrate. This can lead to race conditions (found in our application).

In addition, there are now #shuffle, #shuffled, #shuffleBy: and #shuffledBy: where #shuffled and #shuffledBy: shuffle a copy and answers that. This is very confusing.

I propose a fix where #shuffled and #shuffledBy: are renamed to #copyShuffle and #copyShuffledBy: and moved to the "copying" protocol. #shuffle and #copyShuffle will use the mutex to prevent race conditions.