Feature #11824


Add Enumerator#to_ary for added implicit behavior

Added by danielpclark (Daniel P. Clark) almost 7 years ago. Updated almost 7 years ago.

Target version:


Calling Enumerator#to_a many times can become a bit ugly in a code base. I propose these changes to Enumerator to allow implicit Array use of all Enumerators.

class Enumerator
  def to_ary

  def method_missing m, *a, &b
    return to_a.send(m, *a, &b) if Array.instance_methods.include? m

Updated by danielpclark (Daniel P. Clark) almost 7 years ago

Perhaps I was too hasty posting this? According to Matz about 6 years ago this didn't seem the right thing to do.


In message "Re: [Bug #1893] Recursive Enumerable#join is surprising"
on Wed, 3 Mar 2010 00:57:26 +0900, Yusuke Endoh writes:

|I guess adding Enumerator#to_ary is a right solution.

I don't think so, supplying to_ary means that object can be considered
as an array, which is not always the case.


Maybe things have changed since Ruby 1.9.2 on this issue? I've been reading through the other issue thread and I'm not sure it would be a bad thing. Most of the methods from Array are already defined and it would save a lot of to_a calls from being written. It would make the following methods available on Enumerators.

Array.instance_methods - Enumerator.instance_methods
# => [:[], :[]=, :at, :fetch, :last, :concat, :<<, :push, :pop, :shift, :unshift, :insert, :each_index, :length, :empty?, :index, :rindex, :join, :reverse, :reverse!, :rotate, :rotate!, :sort!, :sort_by!, :collect!, :map!, :select!, :keep_if, :values_at, :delete, :delete_at, :delete_if, :reject!, :transpose, :replace, :clear, :fill, :slice, :slice!, :assoc, :rassoc, :+, :*, :-, :&, :|, :uniq, :uniq!, :compact, :compact!, :flatten, :flatten!, :shuffle!, :shuffle, :sample, :permutation, :combination, :repeated_permutation, :repeated_combination, :product, :bsearch, :pack]

Updated by marcandre (Marc-Andre Lafortune) almost 7 years ago

  • Status changed from Open to Feedback

I'm pretty certain that it's still quite a bad idea.

Can you provide any argument why anything would have changed? Otherwise we'll close this.

Updated by danielpclark (Daniel P. Clark) almost 7 years ago

Other than syntactic cleanliness and possible public opinion, unfortunately no I don't have a compelling reason why things would have changed.

I think what I'd really like is to not have to call to_a on Enumerators for anything actionable (any verbs). I think you're right it may be a bad idea as many systems may have issue with this.

I suppose I could write my own custom class EnumArraytors ;-). It's probably best practice to create new classes rather than change how the language itself fundamentally works. Or I could use a Refinement to do this in my own projects whenever I want to clean the code base up.

Thanks for at least giving me an opportunity to defend the idea. It was worth considering the options available.

UPDATE: I just learned how to write my own Enumerator::Lazy implementation. This was actually what I was looking for to allow duplicate method implementation for Feature #11815 . This solves the issue of why I opened this feature suggestion in the first place.


Also available in: Atom PDF