Project

General

Profile

Actions

Bug #15428

closed

Refactor Proc#>> and #<<

Added by zverok (Victor Shepelev) over 5 years ago. Updated 7 months ago.

Status:
Feedback
Assignee:
-
Target version:
-
[ruby-core:90591]
Tags:

Description

#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 1 (0 open1 closed)

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

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0