From: Kristof Bastiaensen <kristof@...>
Date: 2004-08-11T07:31:30+09:00
Subject: Re: empty? and size in Enumerable

Hi,

On Tue, 10 Aug 2004 23:11:43 +0200, Robert Klemme wrote:
>> My concern was if #each created a temporary data structure in O(n) time
>> (e.g. an ordered hash) - this would make sense for #each, since its
>> running time is O(n) anyway, but would be a large hit for empty?
> 
> Hm, that's true.  Although that argument would not stop me from advocating
> #empty?  Runtimes of each enumerable class differ anyway.  Classes
> override this method usually anyway.  It's a different case with #size
> which has been shown to not terminate for certain non totally esoteric
> implementations.
> 
> Here's maybe another reason: emty? and size both depend on an Enumerable
> with a deterministic amount of elements.  This need not always be the
> case:
> 
> class RandEnum
>   include Enumerable
> 
>   def each
>     rand(10).times { yield rand 20 }
>     self
>   end
> end
> 

That's all nice and esoteric, but I don't see why it is a
reason against empty? or size.  In fact, if that would be
important, than the other methods in Enumerable shouldn't
also be there.  Take for example the following:

  require "enumerator"
  to_enum(:loop).map

There is nothing that prevents that.  In fact I currently have
irb eating up slowly all the memory. Does that mean there
shouldn't be a map method?  I think it is possible to find
pathological cases for the other methods in Enumerable 
(I'll leave that as an exercise for the reader).

IMO the reason against size is that is not possible to implement
efficiently.  As for empty?, I don't know.  I find it useful,
and as shown by other people easy to implement.

Cheers,
KB