Phil Tomson wrote:

> This is all very useful and cool.... any possiblity that it will end up in
> Ruby's built-in library?

I'd like to see that ;)

One concern would be the different approach to iteration using
delegation. Mixing this approach with the usual Enumerable methods, like
#collect, might be confusing because #collect doesn't delegate, it just
goes ahead and creates the new collection. If you change the original
collection, the output of #collect is not affected, whereas the output
of #product still refers to the changed version. This won't usually
matter if you're just chaining methods without saving the intermediate
collections. But the following could cause confusion:

  set1 = (1..100).to_a
  set2 = (2..200).to_a
  prod = product(set1, set2)
  set1.delete(1)
   ...

If you adhere to a functional style of programming, you avoid this kind
of thing. But Ruby appeals to people who like all kinds of styles.

It might be nice to have versions of collect and select and so on that
_do_ delegate, so that you can chain them more efficiently, like a pipe,
without generating large temporary arrays:

  (0..10000).delegate_collect { |x| x**2 }.select { |y| y > 1000 && y <
2000 }

But this is all an optimization, and the Ruby way seems to emphasize
conceptual clarity over optimization. If there is a #product in the
built-in library, maybe it would be better not to use my approach, but
to explicitly generate the array of tuples. Save the optimization for an
outside library.

--
Joel VanderWerf                          California PATH, UC Berkeley
mailto:vjoel / path.berkeley.edu                     Ph. (510) 231-9446
http://www.path.berkeley.edu                       FAX (510) 231-9512