[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ruby-core
Subject:    Re: ANN: Free-form-operators patch
From:       "trans.  (T. Onoma)" <transami () runbox ! com>
Date:       2004-10-12 1:23:38
Message-ID: 200410112123.33703.transami () runbox ! com
[Download RAW message or body]

On Monday 11 October 2004 08:09 pm, Markus wrote:
| unlike the issue Proc.new()
| automatically exploding single array argument (which would break a fair
| amount of production code for me)

That reminds me.... on suby-ruby I brought up that Enumerable "each-related" 
methods like #select and #find_all, etc. do not pass arguments. In other 
words if my Enumerable class defined

  class MyEnum
    include Enumerable
    def each(arg0, arg1, ...)

I'd be out-of-luck, and have to write all the Enumerable methods by hand. Can 
the Enumerable methods be defined to pass on arguments? i.e.

  def select(*args)
    each(*args) { ...

 
Another point, Mauricio Fernández saw this and thought I meant that the 
argument might determine the number of parameters:

  a = [0,1,2,3,4,5,6,7,8]
  each(3) { |a1,a2,a3| puts "#{a1},#{a2},#{a3}" }
  => 0,1,2
     3,4,5
     6,7,8

To which I replied that I have my own method called Array#each_by just for 
that purpose. But I realized it should be in Enumerable not Array, and 
likewise this would suggest a #select_by, #collect_by, #find_all_by, etc. 
That seems like a lot of extra methods for something so basic. So then I 
wondered, could #each count the arity of the block instead?

Obviously this comes into conflict with how block parameters are currently 
exploded against arrays-in-arrays. Similar topics has come-up a number times 
lately, and per Markus' investigation there is some oddity a foot. I wonder 
if the behavior can't be substantially improved for 2.0. (I know it may break 
code, but if there is ever a time to do so, it is present.)

T.



[prev in list] [next in list] [prev in thread] [next in thread]