Hi --

On Mon, 23 May 2005, Eric Mahurin wrote:

>> #flatten has no general
>> meaning for an enumerable, since not all of them are
>> recursive container objects.
>
> Array#flatten only descends into Array elements, and an
> Enumerable#flatten might only descend into Enumerable (or
> Array) elements.

It just seems like a bad fit for, say, iterating through lines of a
file.  I don't think being enumerable implies being flattenable,
because it doesn't imply being nested (whereas being an array implies
that you might be nested).  Therefore I wouldn't put flatten in
Enumerable.

>> I don't think you can #pack an arbitrary
>> enumerable either.  #size also doesn't work for enumerables
>> in
>> general, partly because some of them have no particular size
>> and
>> partly because even for those that do, taking the size might
>> cause
>> side-effects (e.g., an I/O-based enumerable).
>
> Using any enumerable method with IO has the same issue.  You'll
> need to seek back between calls to any of the enumerable
> methods on an IO.

Size has the other problem too: being enumerable does not mean being
measurable.  For example:

   class C
     include Enumerable
     def each
       loop { yield rand(100) }
     end
   end

It's meaningless to talk about the size of a C object -- but it's a
perfectly legitimate enumerable.

> Of course their is an easy (but not quite as efficient) way to
> do any of the array methods on an enumerable: just call to_a
> first (i.e. enum.to_a.join(" ") does a join for any
> enumerable).

I'm not sure that it's less efficient than some of these.  For
example, see the exchange earlier in the thread about to_a vs. inject
in join; the efficient inject seemed to benchmark around the same as
to_a (though presumably this would vary from one case to another).  Of
course, I'm not sure one of my C objects, above, would respond to
nicely to to_a.... :-)


David

-- 
David A. Black
dblack / wobblini.net