From: Simon Strandgaard <neoneye@...>
Date: 2004-04-13T09:44:14+09:00
Subject: Re: zip block oddities/bug?

On Tue, 13 Apr 2004 08:01:41 +0900, Mark Hubbart wrote:
> On Apr 12, 2004, at 2:39 PM, Simon Strandgaard wrote:
>> On Mon, 12 Apr 2004 15:40:06 +0000, Martin DeMello wrote:
>>> Note the difference:
>>>
>>> a.zip(b,c).map {|i| ... } # builds the array, then iterates over it
>>> a.zip(b,c) {|i| ... }      # generates values one by one and calls 
>>> block
>>>
>>> If the latter functionality were not built into zip, there'd be no way
>>> to do it from 'outside', short of using a continuation. As daz points
>>> out, there are definitely times you'd want to iterate without building
>>> either an intermediate or an output array.
>>
>> I think thats a broken metaphor, to do multiway each by means
>> of zip.
>>
>> I don't wanna defend my idea any longer (too much resistance).
>> Isn't there any which can say something positive.. or agree with
>> me on this ?
> 
> I would have to agree with you on this... it doesn't make sense to me 
> that the block version doesn't collect the output of yield.
> 

Great. (I was beginning to worry if it were a silly idea of mine)


> That said, I can definitely see the benefit of having it *not* collect 
> the output. I would just tend to think that the non-collecting one 
> should not have the same name as the collecting one. Perhaps:
> 
>    (4..6).zip(10..12)  #=> [[4, 10], [5, 11], [6, 12]]
>    (4..6).zip(10..12) {|a| a[0]*a[1] } #=> [40, 55, 72]

or a little shorter

 (4..6).zip(10..12) {|a,b| a*b } #=> [40, 55, 72]

 
> and
> 
>    (4..6).zip_each(10..12) {|a| puts a[0]*a[1] } #=> nil
> 
> But then this would break a lot. Even if people agree with this, I 
> wouldn't expect to see it before 2.0
> 

Agree.. thats the reason I mentioned it, so we can break as
much as possible in the transition from 1 to 2.

--
Simon Strandgaard