From: Robert Dober <robert.dober@...>
Date: 2009-06-19T17:57:05+09:00
Subject: Re: each by arity

On Fri, Jun 19, 2009 at 8:35 AM, Robert
Klemme<shortcutter@googlemail.com> wrote:
> 2009/6/19 trans <transfire@gmail.com>:
>
>> Perhaps, but I must think about it some more. Presently one would do
>> (in 1.9):
>>
>>  coll.each_slice(n){ ... }
>>  coll.each_cons(n){ ... }

No It would be
   coll.each_cons # this is the proxy, it does not know about the slice size yet
     .map{ |a,b|  ... }  # the proxy will look at the arity.
>>
>> If one wanted to map over that:
>>
>>  coll.map.each_slice(n){ ... }
>>  coll.map.each_cons(n){ ... }
>>
>> correct?
>
> For mapping in 1.9 I would do
>
> coll.each_slice(n).map{ ... }
> coll.each_cons(n).map{ ... }
>
>> So how do we best achieve "by arity" without stepping on present toes?
>
> I would simply stick with the existing behavior. :-)

I will not let the absence of use cases let ruin my work ;) Now I have
always liked Tom's reach for perfection, but on a practical base I
agree with Robert it is probably not worth it.

But on a theoretical ground I find it intriguing that the "proxy"
would do something similar to what an enumerator does.
An enumerator prepares a view of an enumerable for an actual method
delivering the behavior in a block.
One could say it "waits" for a message with a block.
The proxy will wait for a message too, and a block too, and will just
create the Enumerator on the fly with the information of the arity.
I even wonder if Enumerator could be the proxy with a little monkey
patch? And that might as well lead to a "default" behavior for map,
without the "proxy method" which would meet Tom's original requirement
for Enumerators *only*

Thus  [1,2,3].map{|a,b| [a,b]} would still be [[1, nil]....]
*but*
[1,2,3].to_enum.map{|a,b| [a,b]} would be [[1,2],[3,nil]]


Cheers
Robert