Re: ANN: Free-form-operators patch

Hi,

In message "Re: ANN: Free-form-operators patch"
    on Tue, 12 Oct 2004 10:23:38 +0900, "trans.  (T. Onoma)" <[e-mail]> writes:

|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) { ...

No.  Something more than simple iteration must be done via Enumerator,
in my opinion.  If it would result the request for Enumerator
enhancement, that's fine for me.

|Another point, Mauricio Fern疣dez 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?

The arity of blocks will be able to get reliably in the future.  But
I'm not sure if it's a good idea to change behavior based on it.
Anyway, I'd suggest Enumerator for this purpose too.

|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.)

I will take time to examine threads about "yield semantics".
I promise.

							matz.