From: gotoken@... (GOTO Kentaro)
Date: 1999-07-13T10:52:58+09:00
Subject: [ruby-talk:00474] Re: Now another totally different ;-)

In message "[ruby-talk:00471] Re: Now another totally different ;-)"
    on 99/07/12, Clemens Hintze <c.hintze@gmx.net> writes:
>>Of course, one can define `[]' via `each'. I can't ban doing that :-)
>
>That is not the point! Only Enumerable would do it that way (using
>`each'), as a new class includes module Enumerable has to implement an
>own `each' method on any case.
>
>Only If the new class DOESN'T implement an own `[]', then that thump
>one of Enumerable would be used and would offer a fall-back
>possibility.

I see. Your opinion also seems right. The matter to consider may be
the degree of benefit in daily programming. That is, how general
enumerable classes become convenient by Enumerable#[].

First, let's consider predefined classes. Those can be classified into
three groups:

  (1) Enumerable  &&  has []
    (1.1) x.to_a[i] == x[i]
      Array, Struct
    (1.2) x.to_a[i] != x[i]
      Hash, String

  (2) Enumerable  && !has []
       Dir, File, IO, Range, Struct::Tms, Struct::Stat

  (3) !Enumerable &&  has []
       Bignum, Fixnum, Proc, Method, Thread, Match

Under my own criterion, Only File and Range are naturally will be held
x.to_a[i] == x[i]. IO and Dir are not suitable to be so,  because IO
is nondeterministic, dir[i] is just not natural. 

The above discussion may be not enough to decide to reject Cle's
Enumerable#[], but I feel such [] is too special yet. 

>># Don't be fed up with my obstinacy, Cle. 
>I am not fed up, be sure. Only I fear you will, Gotoken. :-}

I'm being amazed how many you you make new proporsals! =)

-- gotoken