Issue #13904 has been updated by knu (Akinori MUSHA).


Enumerator is about abstracting enumeration and encapsulation of the source is by design.  If we exposed the guts of an Enumerator, people would start to look into the enclosed object and do (I think are) evil things for optimization and specialization, which should be in the opposite direction of abstraction.  If you expect something other than a one-way, not necessarily rewindable stream, I think you should create a new model that describes the aspect by sub-classing Enumerator or making a mix-in.

In summary, if you want to handle a numeric enumerator specially, I'd say you should create a class for that instead of making surrounding methods guess or find out what they receive is special by invesigating its internals.  It shouldn't be a good way to introduce a new idea to the language.

----------------------------------------
Feature #13904: getter for original information of Enumerator
https://bugs.ruby-lang.org/issues/13904#change-66738

* Author: znz (Kazuhiro NISHIYAMA)
* Status: Open
* Priority: Normal
* Assignee: knu (Akinori MUSHA)
* Target version: 
----------------------------------------
At https://gitter.im/red-data-tools/ja?at=59b0aaa097cedeb04828e268 ,
mrkn says narray and pycall use internal information of ruby to check `Range#step(n)`.

People of red-data-tools/ja suggest subclass of Enumerator.
But I think it does not match Ruby's '大クラス主義' (I don't know this word in English), so I suggest to add some methods to Enumerator class.

proof of concept attached.

Usage:

```
% irb -r irb/completion --simple-prompt
>> e=(1..2).step(3)
=> #<Enumerator: 1..2:step(3)>
>> e.receiver
=> 1..2
>> e.method_name
=> :step
>> e.arguments
=> [3]
```

`#method` is conflict with `Kernel#method`, so use `#method_name` instead.


---Files--------------------------------
poc.diff (1.42 KB)


-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>