From: shyouhei@... Date: 2018-05-18T03:24:09+00:00 Subject: [ruby-core:87157] [Ruby trunk Feature#14390] UnboundMethod#to_proc Issue #14390 has been updated by shyouhei (Shyouhei Urabe). Thank you for the explanation. So as far as I understand what you want to do is not just UnboundMethod#to_proc, but a lot more. Seems you are drawing a quite big picture covering structure of code flows. So far I see this UnboundMethod#to_proc feature itself is not that useful, but understand the motivation behind this proposal. ---------------------------------------- Feature #14390: UnboundMethod#to_proc https://bugs.ruby-lang.org/issues/14390#change-72147 * 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: