From: Intransition <transfire@...>
Date: 2011-07-25T08:16:59+09:00
Subject: Re: Better name for #zip_with



On Jul 18, 1:25 pm, Robert Klemme <shortcut...@googlemail.com> wrote:
> Thomas Sawyer wrote in post #1011313:
>
> > On Jul 17, 10:36pm, John Feminella <jo...@bitsbuilder.com> wrote:
> >> How about #zip_and_map? Notice that:
>
> >> > a.zip_with(b) { |c, d| ... }
>
> >> is the same as the result of
>
> >> > a.zip(b).map { |c, d| ... }
>
> > Ah, right. `#zip_map` would makes sense then. But per your last post,
> > I think I may override #zip itself.
>
> Not sure whether I find this a good idea.  Reason: #map has overhead of
> creating a new Array with the same length as the input.  That should not
> be the default behavior IMHO.  A clean separation would be
>
> [].zip([]) => Enumerator
> [].zip([]) {|a,b| ...} => nil (as today) or self (i.e. leftmost Array)
>
> Then we can efficiently have [].zip([]).map {|a,b| ...}
>
> But it would break old code. :-(
>
> So, today for efficient zip + map we would have to do
>
> [].enum_for(:zip, []).map {|a,b| ...}

Thanks. If I add to Facets I'll utilize this.

I'm starting to think, however, that it makes more sense to add
optional arguments to #map itself. Consider that #zip returns an assoc
array, that's it's expected behavior. So it's probably best not to
alter that. Whereas map can return any form of array based on the
block.

    [1,2,3].map([2,3,4], [5,6,7]) { |a,b,c| ... }

Map has free arguments, so why not?