From: Benoit Daloze <eregontp@...>
Date: 2010-09-18T00:52:53+09:00
Subject: [ruby-core:32463] Re: [Backport #3715] Enumerator#size and #size=

On 23 August 2010 19:44, Run Paint Run Run <runrun@runpaint.org> wrote:
>>> 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.

Yes, the only thing is returning a Float does not seems right (ideally
it should be an Integer infinity, but that is no sense in the
implementation). So, I guess Infinity is a good answer.

>> �* 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.

So, what about using Marc-Andr� work to improve Enumerable#count (with
no arguments or block),
 by defining #size in the Enumerator which can support it, and make
#count behaves the way described (I quoted it earlier)
  (check if #size is defined, and then just call it).

The block form seems rather complicated and can easily be done in
other ways, if I understand correctly, so I think this should not be
implemented right now.

The only problem is then #count for iterators which have side-effects
as Array#drop_while,
 but who would want to actually have an efficient way to #count
something like that ?

I think a solution is simply to not implement #size for these (so not
implement for the enumerators which mutate the receiver), as it is not
interesting and may give an unexpected result (eg: actually not
dropping the elements).

I would like to contribute to this feature, and so to adapt the patch
with what I just described.

Does it seems a good idea to you, should I go ahead?
Marc-Andr�, are you according to this? (do you want to do it yourself,
is it ok I work with your code ?)

The first thing would then to make a list of enumerators for which we
define #size,
 and to choose if we implement it for infinite enumerators, or let it
loop forever.

Regards,
B.D.