Issue #13904 has been updated by knu (Akinori MUSHA). Well, this issue states that the motivation for introducing the getter methods is for getting return values of Range#step(n) to be handled specially by some libraries or individual methods, and as I said it is to me a typical misuse of such accessors I've been thinking of and I believe there's a better way to achieve the goal, so I can't buy that argument. I can hardly believe you'd be happy (at the cost of introducing a new feature) if you had to check `x.instance_of?(Enumerator) && x.receiver.is_a?(Numeric) && x.method_name == :step` every time your method was passed an object that might be a step object. It really looks like you are doing some hack as the last resort because you don't have anything better yet. If stepped range objects are useful, they deserve a new class for their own. ---------------------------------------- Feature #13904: getter for original information of Enumerator https://bugs.ruby-lang.org/issues/13904#change-66753 * 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>