On 23 September 2013 14:17, Nicolas Cellier <[email protected]> wrote: > 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.
Especially since locks don't compose. If you _really_ cared about accessing something concurrently, you'd share immutable data structures. frank > 2013/9/23 Max Leske <[email protected]> >> >> 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. > >
