[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
-- [e-mail]

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