Hi --

On Tue, 19 Nov 2002, Bob Alexander wrote:

> On "zip":

[very interesting comments snipped]

> One of the reasons I don't like using Python's "zip" is that it actually
> zips up all of the input sequences into a physical result sequence (similar
> to their "range" function which is semantically like Ruby's "m...n" but
> returns a physical sequence) -- it's always bothered me to have to create a
> possibly large sequence to do that operation when it isn't necessary.
> Hopefully, if "zip" becomes part of Ruby, the implementation could be as an
> iterator which never builds a physical version of the zipped sequence. But
> that is an implementation challenge if the input sequence are general
> instances of Enumerable, since the input sequences cannot be efficiently
> iterated in parallel. (If the input Enumerables were limited to those which
> are numerically indexed, such as Arrays, implementation would be easy -- but
> it would be unfortunate to have to make that restriction.)

I'm not sure the numerical indexing is such a bad restriction.
There's always to_a and/or to_ary....  Besides, perhaps very wrongly,
I always think of enumerables as, by definition, ordered sequences,
which can always be numerically indexed.  (Which is why I don't think
that hashes should be Enumerables, but that's another story :-)

> Anyway, my personal feeling about "zip" is that I would likely use it only
> if it could efficiently iterate the zipped elements of the input sequences
> without creating a full physical output sequence. Otherwise, I don't think
> it's especially useful.

Just to clarify: does that include a sequence of (I think) pointers?
I'm thinking along the lines of the component objects themselves not
being duplicated... but I don't know whether that's relevant to your
point.


David

-- 
David Alan Black
home: dblack / candle.superlink.net
work: blackdav / shu.edu
Web:  http://pirate.shu.edu/~blackdav