From: zverok.offline@... Date: 2018-05-17T11:46:20+00:00 Subject: [ruby-core:87134] [Ruby trunk Feature#14390] UnboundMethod#to_proc Issue #14390 has been updated by zverok (Victor Shepelev). @shyouhei the point is in gradual enchancing Ruby's approach to functional/declarative chaining. Let's look at this example: ```ruby (1..3).each(&method(:print)) (1..3).each { |i| print i } ``` The second, in fact, is _shorter_, but (at least for me) the first somehow feels more "right" even in this case: for example, because it is more DRY (no "define i ��� immediately use i"); but also, it forces to structure code flow clearly (e.g. instead of hairballs of large blocks chained, I tend to think about code structuring in "processed by this method, then processed by that method"). Now, when the basic usability of `&method(...)` is aknowledged by some, when it would be shortened (I hope), it will be an awesome tool of writing short and clean code. Also, I believe that some room of optimization is present here, e.g. if some proc "knows" (and, at C level, it knows) it is just a Method, then it can be passed and called with less overflow. Closer to the topic of current issue: The baseline is this: ```ruby map{|i| i.dig(:foo :bar, :baz) } ``` And looking at things like `map(&:size)`, lot of people invent things like: ```ruby .map(&:dig(:foo, :bar, :baz)) # or .map(&:dig.(:foo, :bar, :baz)) ``` ...which is interesting but somehow "spheric in a vacuum": what is this syntax? whose responsibility is to maintain it? How should it be read and parsed? So, what I am trying to think about, is not the necessary _shorter_ code, but conceptually more clean. If the concepts are there, it can be shortened to a special syntax later (like `&method(:foo)` ��� `&.:foo` is planned currently). So, my idea was (I am not sure about it, but I believe that at least introduction of `UnboundMethod#to_proc` would not _harm_ anybody or anything) that ```ruby map(&Hash.instance_method(:dig).rcurry[:foo :bar, :baz]) ``` ...is not a _better_ way of doing things, just a way that _can_ be made available, to see what optimization and code style techniques can emerge. It is somehow "logical" to say that `.map(&:dig.(:foo, :bar, :baz))` is "rendered" as "call instance method with thouse arguments bound to it". ---------------------------------------- Feature #14390: UnboundMethod#to_proc https://bugs.ruby-lang.org/issues/14390#change-72121 * Author: zverok (Victor Shepelev) * Status: Feedback * Priority: Normal * Assignee: * Target version: ---------------------------------------- I believe that it could be somewhat useful to have UnboundMethod converted to proc (accepting the object to bind to, as a first argument). Practical(ish) example, paired with [Proc#rcurry](https://bugs.ruby-lang.org/issues/11161) proposal: ```ruby URLS. map(&Faraday.method(:get).rcurry[some_get_param: 'value']). map(&JSON.method(:parse).rcurry[symbolize_names: true]). map(&Hash.instance_method(:dig).rcurry[:foo :bar, :baz]) ``` It is somewhat more verbose than a lot of alternative proposals for "shorthand of &method call with arguments", yet requires no changes in parser or language design. With some future shortcuts/operators for `#method` and `#instance_method` it can even become pretty short and look like an "idiom". PS: For the reference, shorthand that was proposed and rejected several times (see #6483, #4146): ```ruby ...map(&:dig(:foo :bar, :baz)) ``` As it is indeed looks much shorter than my proposal, it raises a lot of question about what is that `:dig(:foo :bar, :baz)` and how it should be parsed and whether it can appear outside of `&`-calls. -- https://bugs.ruby-lang.org/ Unsubscribe: