Forum: Ruby-core [Feature #3714] Add getters for Enumerator

Feature #3714: Add getters for Enumerator
http://redmine.ruby-lang.org/issues/show/3714

Author: Marc-Andre Lafortune
Status: Open, Priority: Normal
Category: core, Target version: 1.9.x

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.

Hi,

On 18 August 2010 21:51, Marc-Andre Lafortune <redmine@ruby-lang.org> 
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.

Issue #3714 has been updated by Run Paint Run Run.


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?
----------------------------------------
http://redmine.ruby-lang.org/issues/show/3714

Issue #3714 has been updated by Akinori MUSHA.

Status changed from Assigned to Feedback
Priority changed from Normal to Low

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?
----------------------------------------
http://redmine.ruby-lang.org/issues/show/3714

Issue #3714 has been updated by Run Paint Run Run.


> 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.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/3714

Hi, knu

2010/8/29 Akinori MUSHA <redmine@ruby-lang.org>:
> 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 ;-(