Project

General

Profile

Actions

Feature #3714

closed

Add getters for Enumerator

Added by marcandre (Marc-Andre Lafortune) over 13 years ago. Updated over 6 years ago.

Status:
Closed
Target version:
[ruby-core:31761]

Description

=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


Related issues 3 (0 open3 closed)

Related to Ruby master - Feature #3715: Enumerator#size and #size=Rejected08/19/2010Actions
Related to Ruby master - Feature #14044: Introduce a new attribute `step` in RangeRejectedmatz (Yukihiro Matsumoto)Actions
Has duplicate Ruby master - Feature #13904: getter for original information of EnumeratorClosedmrkn (Kenta Murata)Actions
Actions #1

Updated by Eregon (Benoit Daloze) over 13 years ago

=begin
Hi,

On 18 August 2010 21:51, Marc-Andre Lafortune 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

Actions #2

Updated by runpaint (Run Paint Run Run) over 13 years ago

=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

Actions #3

Updated by shyouhei (Shyouhei Urabe) over 13 years ago

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

=begin

=end

Actions #4

Updated by knu (Akinori MUSHA) over 13 years ago

  • 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

Actions #5

Updated by runpaint (Run Paint Run Run) over 13 years ago

=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

Actions #6

Updated by mame (Yusuke Endoh) over 13 years ago

=begin
Hi, knu

2010/8/29 Akinori MUSHA :

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

=end

Updated by yhara (Yutaka HARA) over 11 years ago

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

Updated by marcandre (Marc-Andre Lafortune) about 11 years ago

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

Actions #9

Updated by knu (Akinori MUSHA) over 6 years ago

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

Updated by marcandre (Marc-Andre Lafortune) over 6 years ago

  • Status changed from Open to Closed
Actions #11

Updated by mrkn (Kenta Murata) about 6 years ago

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

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0