Feature #11824
closedAdd Enumerator#to_ary for added implicit behavior
Description
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
Updated by danielpclark (Daniel P. Clark) almost 10 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.
Hi,
In message "Re: [Bug #1893] Recursive Enumerable#join is surprising"
on Wed, 3 Mar 2010 00:57:26 +0900, Yusuke Endoh redmine@ruby-lang.org 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]
Updated by marcandre (Marc-Andre Lafortune) almost 10 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 10 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.