From: "David A. Black" Date: 2004-08-03T22:32:40+09:00 Subject: Re: Request for two methods in Array class 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 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