On Mar 6, 2004, at 1:17 PM, David A. Black wrote:

> On Sun, 7 Mar 2004, Mark Hubbart wrote:
>> It's not redefining rand to take more varied arguments that's a bad
>> thing, it's defining it for Array#rand that's a Bad Idea(tm), IMHO.
>> Kernel is included in Object so that you can access it's methods 
>> easily
>> within other objects. Redefining it in a subclass could potentially
>> break lots of code. For example, I often do this:
>>
>>    class Array
>>      def randomize()
>>        sort{rand(2)-0.5}
>>      end
>>    end
>>
>> ... and defining an Array#rand would break this.
>
> You must not be very fond of IO#gets, Thread#exit, Dir::open, or
> Proc#binding :-)  Which is to say -- there are cases where Kernel
> methods we use without a receiver do get redefined for specialized
> purposes.

point taken :) Still, with IO#gets and Thread#exit (I admit I haven't 
used the others), the kernel methods were redefined so that they would 
make more sense in the context. My beef with Array#rand is that it 
redefines it to do something very _different_ from what the Kernel 
method does. Kernel.rand *generates* a random number within parameters, 
the proposed Array.rand would *select* a random element from a list. 
Maybe it's only a distinction I make in my head :)

> However, while it's moot anyway because of my fatal
> Enumerable#size flaw, my snippet was really just to show the behavior
> we were discussing on IRC.

Just because it can't be added to Enumerable, doesn't mean it should be 
nixed. I would certainly still want it in Array, personally. I just 
think it should have a different name. :)

> No endorsement of reckless endangerment of
> Kernel intended :-)

:)

BTW, the reason I'm fairly strong against Array#rand is because I added 
that exact method into my personal "utils" library a while back, and 
suddenly a lot of my scripts started failing. It took me a while to 
figure out where the problem was. :)

--Mark