Bug #15428

Refactor Proc#>> and #<<

Added by zverok (Victor Shepelev) almost 2 years ago. Updated over 1 year ago.

Target version:


#6284 introduced Proc#>> and Proc#<<, but the requirements to the argument is totally inconsistent with ANY other place in Ruby.

Currently, it is the only place in Ruby where coercing argument to Proc is done with #call method. Everywhere else it is done with #to_proc, and #call method never had any special significance except for .() sugar. I believe there are two possible actions:

  1. change #>> and #<< to use #to_proc (which will give Symbols composability for free), or, alternatively
  2. state that #call from now on has a special meaning in Ruby and probably decide on other APIs that should respect it (for example, auto-define #to_proc on any object that has #call)

Either is OK, the current situation is not.

PS: One more problem (that probably should be discussed separately) is that check for #call existence is performed pretty late, which can lead to this kind of errors:

# At code loading time:

# I erroneously thought this is correct. It is not, but the line would perform without
# any error.
PROCESSOR = JSON.method(:parse) >> :symbolize_keys 

# Later, in runtime:
'{"foo": "bar"}'.then(&PROCESSOR)
# NoMethodError (undefined method `call' for :symbolize_keys:Symbol)

UPD 2018-12-29: As this ticket was ignored prior to 2.6 release, I rewrote it in an "actionable" instead of "question" manner.

Related issues

Related to Ruby master - Feature #15483: Proc or Method combination with SymbolRejectedActions

Also available in: Atom PDF