From: Jim Weirich Date: 2008-08-04T04:03:00+09:00 Subject: [ruby-core:18109] Re: New array methods cycle, choice, shuffle (plus bug in cycle) On Aug 3, 2008, at 12:50 PM, Dave Thomas wrote: > So I'm thinking that the methods that _should_ get added to the > standard library should be the ones that are tricky to implement, or > that have performance problems if not in C. But > > class Array > def sample > at(rand(length)) > end > end > > Doesn't seem like a lot of work to ask of a programmer. On the handful of occasions that I have needed this, this is exactly what I've done. And although it is easy to do, there are a couple of considerations: (1) Every time I write that from scratch, I mentally stop and think through the boundary conditions to make sure the values returned by rand(length) are not off-by-one w.r.t. array indices. Actually, if I did this *more* often, it would become an idiom that I would write without thinking. But its not that common for me so it is still a (minor) mental exercise every time I write (and read) that. (2) If I were doing this in a reusable library, I have to stop and consider namespace issues and answer the questions will any one else define a "sample" (or "choice", or whatever) method that might collide with my version. This might force me to make a non-array method (i.e. takes array as an argument ... yech), or add code to detect name collisions, or do something else.[1] However, if it was a standardized name, then the namespace issues go away. > Alternatively, perhaps all these peripheral methods could be put > into a mixin? Actually, I kind of like this idea. Keeps it out of the main array interface (which I agree is crowded), but standardizes the name so there is consistency. In the end, I'll be happy with whatever Matz decides to do on this issue. Its really not a big deal. -- -- Jim Weirich -- jim.weirich@gmail.com [1] I long for the day that selector namespaces reduces these issues. [2] [2] But I also fear that selector namespaces will be to Ruby as Generics were to Java.