From: Run Paint Run Run <runrun@...>
Date: 2010-08-24T02:44:36+09:00
Subject: [ruby-core:31831] Re: [Backport #3715] Enumerator#size and #size=

>> I find the semantics of Enumerator#size's block argument confusing.  Maybe
> if it was called "count" instead which is also a verb, it would less
> confusing?

I don't think so. As Benoit notes, Enumerator already responds to #count, with
different semantics.

> Interesting, though I do not feel INFINITY to be the right answer if it is a
> loop (but yes, it should obviously be bigger than anything you compare to).

Infinity makes sense to me given that Object#loop is, indeed, an infinite loop.

>  * but Enumerator#size is not a good API, since not all enumerators would
>    have the way to tell the numbers of items.  Permutations and combinations
>    are rather exceptions.

> I'm not sure I follow. The builtin enumerators can tell the numbers of items
> (more than 70), except a very small number of exceptions (mainly the IO
> ones). Users programming their own enumerators would decide to specify a lazy
> counter if they choose to.

I concur with Marc-Andr��. The bulk of his patch proves that this ability can
typically be retrofitted. The pathological case is an enumerator unable to
calculate its size without iteration, yet to do so would be
impractical--perhaps due to side-effects. However, I see this as analogous to
Range#each inasmuch as it is a method that does not work for certain,
narrowly-defined types of input.