Hi –
[…]
There is a discussion whether Enumerable#zip is appropriate or not.
ex.
- Enumerable.zip(a, b, c…)
- Array.zip(a, b, c…)
- [a, b, c…].zip
How about the latter, with an optional block.
a = [1, 0, 3]
b = [2, 1, 2]
c = [3, 2, 1][a, b, c].zip { |x, y, z| x*y + z } #=> [5, 2, 7]
Now zip is like lisp’s map.
The optional block is cool, but I don’t know about having the return
value of the method being different depending on the presence or
absence of a block. I’m not sure, though.
Many moons ago I wrote Array#braid, which was essentially a
n-dimensional ‘zip’. It returned a “braided” version of the input
arrays:
a.braid(b,c) # => [ [1,2,3], [0,1,2], [3,2,1] ]
and it could take a block:
res =
a.braid(b,c) { |x,y,z| res << x*y+z }
but the actual return value of the method stayed the same. (Not that
my #braid method is a model of Ruby perfection – the extant version
seems to have a rogue concat where a << should be… So it was
more like #each than #map, or something. I don’t know whether there’s
a real underlying reason to do it this way.
David
···
On Fri, 15 Nov 2002, Tim Sutherland wrote:
In article 20021112020739J.maki@rubycolor.org, TAKAHASHI Masayoshi wrote:
–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav