Hi --

On Tue, 3 Aug 2004, Gavin Sinclair wrote:

> On Tuesday, August 3, 2004, 10:59:57 PM, David wrote:
> 
> > Hi --
> 
> > On Tue, 3 Aug 2004, Yukihiro Matsumoto wrote:
> 
> >> Hi,
> >> 
> >> In message "Request for two methods in Array class"
> >>     on 04/08/03, Mike Hall <mghallNO / SPAMenteract.com> writes:
> >> 
> >> |1. A new method, Array.combine  (needs a better name for general use).
> >> |   It takes entries from two (or many) arrays and combines them.
> >> |   (like a combination of Array.zip, fetch, and map)
> >> 
> >> Sounds nice.  But I'm not sure "combine" is a proper name for the
> >> method.   We need more discussion, for example:
> 
> > I know I'm being the voice of possibly excessive conservatism
> > here... but I'm just wondering what this method would give us, since
> > we can already do zip+map.  As Ara said, it would create one less
> > object.  But chaining methods always creates intermediate objects.  If
> > zip+map deserves to be combined into a new, single method, what about
> > flatten+map, or compact+map?  And then (flatten+map)+compact....
> 
> > I realize that zip+map is more likely to be actually used, and people
> > have often said they wish zip's block mapped the elements.  But I
> > still wonder whether it's worth a new method and method name.
> 
> That's good thinking.  The most compelling examples so far have been
> the ones where #zip actually has map-like functionality.  No need for
> a new method.  *Definitely* don't touch #map !!
> 
>   arr.zip { ... }            # same behaviour as arr.map { ... }
>   arr.zip(x) { ... }         #  "    "    "   "  arr.zip(x).map { ... }
>   etc.

The problem with having zip do auto-mapping is that you lose the
ability to do zip with a block but without mapping (which might be
desireable for performance or other reasons).  Whereas if it stays the
way it is, you can always map the results.


David

-- 
David A. Black
dblack / wobblini.net