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

Hi, 

In message "[ruby-talk:00456] Re: Now another totally different ;-)"
    on 99/07/11, Clemens Hintze <[e-mail]> writes:
>>But how we should treat Hash or String?  Some Enumerable classes has
>>its own [].  For example, "abc"[1] != "abc".to_a[1]. 
>
>Please don't take me wrong. If other classes need other behavior,
>they simply overwrite the methods. A class can include
>module Enumerable and so has a lot of methods available. But of
>course if, for certain methods, it behaves other than Enumerable
>would do it, it has to redefine/overwrite these methods!
>
>But it could also use the other ones, defined by module Enumerable,
>okay?

I'm very sorry. I understand your request now (as far as I believe). 

>I know, I know! Unfortunately, IMHO of course, matz has decided
>that `"gotoken"[2]' would not deliver a character but an integer. I
>have struggled many times over this trap!

Well, I think that returning integer value is valid because String
stands a byte string. It is useful when, for example, we treat packed
strings. My misunderstanding was `included module overrides native
methods'. But I've realized that a method of included module is
regarded as one of superclass in case of method search.


>Your class is very interesting :-) So please sorry for being
>obstinate, but...

I love your generous such as being interested even in my tricky
example :-)

>1. Your class is tricky coded. It seems to be a open-end enumeration.
>   So you cannot simply include Enumerable, as that module awaits
>   self-determinish enumerations. Here no method of Enumerable would
>   work well, you have to break that enumeration manually by break.
>   These are not the conditions Enumerable would like to use the
>   `each' method.

But IO<Enumerable has the same characteristics. IO is essentially a 
nondeterministic class. 

>3. But despite the fact, that Trajectory didn't include Enumerable,
>   it could use my proposed `Enumerable#[]' method too. Or implement
>   one of its own, like: 
>
>   class Trajectory
>      def [](i)
>         index = 0
>         each do |element|
>            return element if i == index
>            index += 1
>         end
>         nil
>      end
>   end

Yes, I agree this point. 

>>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,
>
>Oops! I think, I didn't understand your desires here.
>
>>
>>  class FloatWithSucc < Float
>>    def succ
>>      self + 0.3
>>    end
>>  end
>
>I again don't understand it.

Sorry, it might too sudden. I've thought another solution such that we
define succ as an internal iterator on the spot rather than we don't
touch something like Range as an external iterator.  I know Cle wants
a way to specify the step at making an iteration.  I just present an
alternative way. 

Now, if the above works, one can use write as follows:

Foo = String.class_with_succ{|str| str.__succ__.__succ__ }
for s in Foo.new("a")..Foo.new("m")
  p s
end

The following is a utility to work the above (but does work! why?)

class Class
  def class_with_succ(&succ_proc)
    klass = Class.new(self)
    klass.const_set("SUCC_PROC", succ_proc)

    klass.module_eval <<EOS
      alias succ_orig succ
      def __succ__
	self.type.new(succ_orig)
      end

      def succ
	self.type.new(SUCC_PROC.call(self))
      end
EOS
    klass
  end
end


Well, This solution may be not ellegant. 

-- gotoken