To me, the rules are quite clear:
sort shuffle reverse etc... -> perform modification in place

agreed.

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

If you're aware that this convention exists, then ok. BUT: I've been working with Pharo for over 4 years now and I wasn't aware of it. Since we want to make Pharo accessible to new users it is my oppinion that this convention isn't a good one. Especially since messages that answer a copy usually are named #copyXXX. To me, there is no semantical difference between #shuffle and #shuffled, the message names are not revealing in this case (again: personal oppion).

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.

Agreed. BUT: the Random object used by these methods is the same one that is used by #atRandom for instance, hence the race condition. There is no way anyone can safely use these methods without the mutex, single threaded or not. Calls to methods using that same Random object can be all over the place and also in the base system.

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.