[ruby-core:85039] [Ruby trunk Feature#14390] UnboundMethod#to_proc

Issue #14390 has been updated by shevegen (Robert A. Heiler).


> Ugh, seems it duplicates answer-less #10879.

It can probably be referenced to the other report, and your issue
here closed (or the other one; I think it does not matter which
one).

Some issues are unanswered but this does not necessarily mean
that they are not discussed - just sometimes that they may have
lower priority or go "under the radar" as a result.

My suggestion would be - if the issue is important to you, and 
I somewhat agree with you here (primarily because I think it 
would be nice to be able to have UnboundMethod have to_proc too,
simply due to versatility alone, also because it's kind of nice
to be able to detach methods, fiddle around with them, then
attach them back to something... a bit like LEGO blocks for 
kids :D), then you can try to have it registered for the next
ruby developer meeting (the one for january already was only 
some hours ago, so you may have to wait for february; though
matz can of course decide pro/con at any moment in time, but
he often prefers some discussion for various reasons - see
the backtick situation for 3.0).

Anyway, before I write too much, I think it may be better and
easier to provide links:

Wiki to keep track of the developer meetings:

https://bugs.ruby-lang.org/projects/ruby/wiki/Main

Latest developer meeting in January 2018:

https://bugs.ruby-lang.org/projects/ruby/wiki/DevelopersMeeting20180124Japan

Some discussion results of that meeting (not sure if everything has been
logged but matz has said several things about some of the issues discussed
there):

https://docs.google.com/document/d/1q7GaG5KOy5qEKmOAeVucI4CbvYx-nQnSQSfSzyN-9EM/edit

Biggest one is probably when MJIT will be merged. :)

Anyway, if you think that your suggestion is important, I think a ruby core
developer may add your issue to the list for the upcoming meeting. That way
we may get matz' opinion on it eventually - and "two" issues could be approved
or rejected at the same time! :D

(Actually, I think your desscription here is better than the one given in
https://bugs.ruby-lang.org/issues/10879 )

----------------------------------------
Feature #14390: UnboundMethod#to_proc
https://bugs.ruby-lang.org/issues/14390#change-69760

* Author: zverok (Victor Shepelev)
* Status: Open
* 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: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>