Re: Enumerable#zip Needs Love

Hello James,

I think the two changes have to be looked at separately.

At 07:05 08/01/04, James Gray wrote:
>The community has been building a Ruby 1.9 compatibility tip list on  
>my blog.  While most of the changes are good, a pattern is emerging:   
>Enumerable#zip was damaged in the translation.  The short story is:
>
>* Making Enumerable#zip() return and Enumerable::Enumerator when  
>called without a block hid a very useful return value that was already  
>in place.  Now we typically need `enum.zip(...).to_a` to get the  
>expected results.

My recollection may be faulty, and I may not be the typical case,
but I usually have been using zip immediately followed by some
additional operation, which should still work in 1.9, rather
than to produce an explicit array.

>* Beyond being less attractive, Enumerable::Enumerator is quite a bit  
>slower.  It looks like `enum.zip(...).to_a` in 1.9 is about 12 times  
>slower than a straight `enum.zip(...)` in Ruby 1.8.

That looks bad. But have you looked at how much slower or
faster things get when zip is used not just to create an array?
I could also immagine that the zip.to_a combination, and some
similar combinations, could be optimized in the future.

>* Making Enumerable#zip() stop at the length of the shortest  
>Enumerable among the receiver and arguments really hurt its  
>usefulness.  It now discards data and it's hard for us to prevent  
>that, since we need to lengthen all short Enumerable objects we plan  
>to use before the call.  The Ruby 1.8 system of limiting the result  
>set to the size of the receiver was much more powerful, in my  
>opinion.  We could find the longest or shortest Enumerable to get the  
>length we wanted, filter out the `nil` containing groups it inserted,  
>or trim the size of the Enumerable objects involved (easier than  
>expanding them).

I think these arguments make a lot of sense, so I think this
should be moved back to the old behavior, unless there is some
serious implementation problem.

>So, I'm making a plea for restoring Enumerable#zip() to the cool  
>iterator we all know and love:
>
>* Can we restore the Array return value?  We can still use  
>`enum_for(:zip, ...)` when needed.  This fits in with the other  
>iterators that have a useful return value like all?(), any?(),  
>count(), drop(), inject()/reduce(), none?(), one?(), sort(), and take().

Many of these return a single value, where an Enumerable would really
be strange. The only ones that return an array are are drop(), take(),
and sort().

Regards,    Martin.

>* Can we revert to the 1.8 behavior of setting the result set length  
>to the length of the receiver and adding `nil` objects for shorter  
>Enumerable arguments?  That seems to give us a lot more control over  
>the end result.
>
>Thanks for listening.
>
>James Edward Gray II
>
>


#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[e-mail]