Feature #3714: Add getters for Enumerator

• Status: Closed
• Assignee: knu (Akinori MUSHA)
• Target version: 2.6

[marcandre (Marc-Andre Lafortune)]

=begin
Given an enumerator, there is no way to know what receiver, method and arguments it is based upon (although one could use Enumerator#inspect and parse it to get the method).

For sake of completeness and introspection, it could be useful to have access to them.

This patch adds Enumerator#receiver, #method and #arguments: http://github.com/marcandre/ruby/commit/fd4c17f7fd

Note that for Enumerator created with a block like Enumerator.new{|y| y << 1 << 2}, then receiver is a Enumerator::Generator, method is :each and arguments is []. This is consistent with inspect.

Thanks.
=end

[Eregon (Benoit Daloze)]

=begin
Hi,

On 18 August 2010 21:51, Marc-Andre Lafortune [e-mail] wrote:

For sake of completeness and introspection, it could be useful to have access to them.

Do you have any idea for a use case ?

Would it allow to interact better with chained Enumerator ?

Regards,
B.D.

=end

[runpaint (Run Paint Run Run)]

=begin
The information's presence in #inspect output implies its utility. It is a nod to symmetry to allow the arguments with which the enumerator was instantiated to be retrieved subsequently. However, the selector named 'method' is problematic because it shadows Object#method. Perhaps it could be named #name?
=end

[shyouhei (Shyouhei Urabe)]

• Status changed from Open to Assigned
• Assignee set to knu (Akinori MUSHA)

=begin

=end

[knu (Akinori MUSHA)]

• Status changed from Assigned to Feedback
• Priority changed from Normal to 3

=begin
Enumerator was designed as a means to providing a handy and safe way to generate and pass (or return) an Enumerable object without exposing internal details.

So, it was intentional for me as the original API designer not to have provided those accessor methods. For a generator of an Enumerator object, the ingredients are known without a need for such methods. For a consumer, it should only matter that it is an Enumerable object.

Actually, Enumerator#inspect originally did not show anything internal but I changed it to show some just to help debugging. So if the symmetry really matters and you insist on it I'd rather change it back.

These are my points of view after all and you can of course make yours to persuade me. First of alll, can you tell me what use cases you are thinking of?
=end

[runpaint (Run Paint Run Run)]

=begin

Actually, Enumerator#inspect originally did not show anything internal but I changed it to show some
just to help debugging. So if the symmetry really matters and you insist on it I'd rather change it
back.

I certainly don't insist. :-) Your explanation was much appreciated; I concede the argument.
=end

[mame (Yusuke Endoh)]

=begin
Hi, knu

2010/8/29 Akinori MUSHA [e-mail]:

So, it was intentional for me as the original API designer not to have provided those accessor methods. ?For a generator of an Enumerator object, the ingredients are known without a need for such methods. ?For a consumer, it should only matter that it is an Enumerable object.

It is reasonable (for me), but sometimes too strict.

For example, when I want to define my custom Enumerator#inspect, I must
parse the result of original inspect. It is cumbersome.

In general, Ruby does not stop us to shoot our foot. How about providing
methods that Marc-Andre suggested, as private methods?

Actually, Enumerator#inspect originally did not show anything internal but I changed it to show some just to help debugging. ?So if the symmetry really matters and you insist on it I'd rather change it back.

Nooo! The current Enumerator#inspect is really helpful. Do not revert
it ;-(

--
Yusuke Endoh [e-mail]

=end

[yhara (Yutaka HARA)]

• Description updated (diff)
• Target version changed from 2.0.0 to 2.6

[marcandre (Marc-Andre Lafortune)]

• Status changed from Feedback to Open

I can think of two use cases.

I would like to backport some Ruby 2.0 features, and the lack of introspection of Enumerator makes it quite difficult.

1. In Ruby 1.9, Enumerator#each does not accept arguments. This has been fixed in 2.0, but there is no reasonable way to monkeypatch Enumerator#each in 1.9. If these getters existed, that would be easy.

2. Ruby 2.0 introduces Enumerable#size. If the getters existed, it would have been possible to backport Enumerator#size in Ruby for 1.9 without monkeypatching all methods that produce enumerators.

[knu (Akinori MUSHA)]

• Has duplicate Feature #13904: getter for original information of Enumerator added

[marcandre (Marc-Andre Lafortune)]

• Status changed from Open to Closed

[mrkn (Kenta Murata)]

• Related to Feature #14044: Introduce a new attribute `step` in Range added