Feature #11824: Add Enumerator#to_ary for added implicit behavior

• Status: Feedback
• Assignee: -
• Target version: -

[danielpclark (Daniel P. Clark)]

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
    to_a
  end

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

[danielpclark (Daniel P. Clark)]

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

Hi,

In message "Re: [Bug #1893] Recursive Enumerable#join is surprising"
on Wed, 3 Mar 2010 00:57:26 +0900, Yusuke Endoh [e-mail] 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.

matz.

https://bugs.ruby-lang.org/issues/1893#note-7

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]

[marcandre (Marc-Andre Lafortune)]

• 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.

[danielpclark (Daniel P. Clark)]

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.