On Fri, 09 Jul 1999, you wrote:
>Hi, 
>
>In message "[ruby-talk:00440] Now another totally different ;-)"
>    on 99/07/09, Clemens Hintze <c.hintze / gmx.net> writes:
>|
>|1. I think that the mix-in module Enumeration, could also offer a
>|method `[]', as that is easy possible to realize via `each'.
>
>You CAN define it for Enumerable, but I think we don't have to define
>it.  There are some classes which can be enumerable but not indexable,
>for example, Mathematical Set (non-ordered set), and Hash are such
>classes.

I knew you would say that ;-)

But I have another opinion! May I explain my reasons?

1. Every class includes Enumeration can be converted to an Array via
   Enumeration#to_a. So Enumeration#[] could deliver the value which
   would correspond to the combination Enumeration#to_a and Array#[].
   E.g.:
        c = <any class import Enumeration>::new
	# ... fill c
	c[0] == c.to_a[0]

2. If you think that Enumeration#[] is unecessary, why do you think
   Enumeration#index is necessary? These two methods are kind of
   complement, aren't they?
   E.g.:
        c = <any class import Enumeration>::new
	# ... fill c
	e = <any element of `c'>
	i = c.index(e)                     # If that is valid then ...
	e = c[i]                           # ... should also be valid!

3. I have not thought very deeply, but I would think, that every class
   which provides an `each' method, would define a certain kind of
   sequence then! I don't believe that there would be a class, which
   would deliver different sequences during two successive calls of
   e.g. Enumeration#collect. That means:
	c = <any class import Enumeration>::new
	# ... fill c
        a1 = c.collect{|e| e}
	a2 = c.collect{|e| e}
	a1 == a2

4. Non-ordered set would also define a Ruby-internal order. See 3.

>In addition, Hash has non number indexing method [], which
>may be the source of confusion if we define Enumerable#[].

I think that is true for nearly all methods of Hash. As one would
think, that all methods of Enumeration works on the contents, not on
the keys.

I think I would not be confused, as I know, that subclasses have to
redefine all methods to their needs. That's OOP. And including a
mix-in module would not change that necessity.

>
>|2. The operators `..' and `...' cannot be overwritten!
>
>Yes, it's part of the syntax.  Because dots operators appears at
>condition, they work differently.  In reference manual:
>
>   If range expression appears in conditional expression, it gives false
>   until left hand side returns true, it stays true until right hand side
>   is true.  .. acts like awk, ... acts like sed.

That could remain so. If appearing in conditional expressions, do it
like now (complex operation; statement). If it appears in non-conditional
expression, perform a method call (simple operation)!

That is the same as the assignment operator. `a = 1' will be handled
different than `a[0] = 1'. Last one is a method call!

>
>It is possible to call ../... method outside of condition.  It makes
>behavior of the operators bit complex, so we need to discuss about it.
>I'm not sure stepping forward (i.e. make ../... method call) is
>suitable or not.

I would like it, as it would enhance the flexibility of Ruby.

>
>Personally, I don't like mapping operators to method very much.

Here we have found a difference. :-) I VERY like such mapping. So I
basically very like Smalltalk (but not the syntax) and Forth.

>But it is needed to make Ruby handy.  I prefer generic function style
>as in CLOS for mathematical operators, where operands are conceptually
>equal.  But that is too much for the language, enough to abandon to
>include in Ruby.

Hmmm... I don't know CLOS, so I don't know, what they do with
operators.

>                                                matz.

\cle