[ruby-talk:00452] Re: Now another totally different ;-)

Hi, 

>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]

But how we should treat Hash or String?  Some Enumerable classes has
its own [].  For example, "abc"[1] != "abc".to_a[1]. 


By the way, Matz, why the following doesn't print "b\n" but 10?

module Indexed
  def [](n)
    to_a[n]
  end
end

class String
  include Indexed
end

if __FILE__
  p "abcdefg".gsub(/./,"\\&\n")[1]
end

>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

I don't agree it. Because we can define a class which has `each' but 
`collect'. A typical case is potentially infinitely many sequence. 
For example, an mathematical sequence

  class Trajectory
    def initialize(init, &map)
      @init = init
      @map = map
    end

    def each
      s = @init
      loop do
	yield(s)
	s = @map.call(s)
      end
    end
  end

  if __FILE__ == $0
    chaos = Trajectory.new(0.1){|x| 4.0*x*(1.0-x)}
    chaos.each{|x| break if x > 0.99999; p x}
  end

In this case, the halting problem of `each' depends. You may claim
that it is NOT an example of Enumeration but I feel this `each' IS
very `each' because I think an enumeration is a *process* rather than
an *evaluation*, so it should not be restricted to something to halt.
A usage of unbounded `each' is a substitute for `while'. 



By the way, I think the current problem (i.e., our frustration about
Range) came from the lack of easy way to make a subclass which is a
result of appended/modified a kind of methods: for instance,

  class FloatWithSucc < Float
    def succ
      self + 0.3
    end
  end

It doesn't work because the value of succ is not FloatWithSucc. This
kind of difficulty weaken Range, maybe. 

-- gotoken