=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.
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.
=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
=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
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
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 ;-(
I would like to backport some Ruby 2.0 features, and the lack of introspection of Enumerator makes it quite difficult.
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.
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.
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by