[ruby-core:82850] [Ruby trunk Feature#13904] getter for original information of Enumerator

Issue #13904 has been updated by zverok (Victor Shepelev).


> Enumerator is about abstracting enumeration and encapsulation of the source is by design.

Well, to be honest, it seems like "forced encapsulation", and is against Ruby's hackable nature.
I understand your concerns, but if _something_ that even on `#inspect` looks like `#<ClassName x:y>` provides no access to `x` and `y` (though definitely knows them) it just "doesn't feel right".

I believe that composite objects (and enumerator by nature is composite: source + enumeration method) should provide access to what they are composed of, for bad or for good. It is completely possible new ways of interaction and new libraries would emerge in this case.

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

* 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:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>