[ruby-core:91044] [Ruby trunk Bug#15428] Refactor Proc#>> and #<<

Issue #15428 has been updated by zverok (Victor Shepelev).


> `#call` method is called by `Enumerable`, `Enumerator`, finalizer and `Signal`.

That's interesting. I just looked through the docs and understood I was not very aware of this fact:
* `Enumerable#find` (is the only method using `#call`, right?) says just "calls _ifnone_ and returns its result", not specifying how exactly it "calls";
* `Enumerator::new` says "callable object" without further explanation;
* `Signal#trap` says "Otherwise, the given command or block will be run".

OK, that' the problem of docs, I'll handle it. I also never have seen either used in the wild (in a form of "callable object passing"), but maybe it is just me.

Now, from what I can understand, you followed this rule of thumb:
* if something is passed with `&`, it is converted with `to_proc` (it is something that _have some method of coercion_ to a Proc)
* if something is passed as a regular argument, to call later, it is used with `call` (it is something that _think of itself as a kind of Proc_)

So, in fact, it is my "option 2": "codify that `#call` from now on has a special meaning in Ruby", and considering your answer, it is kinda already done since the beginning of time, just not very obvious :)

OK, I can spot 3 problems here:
1. It is not very obvious from documentation and general language structure, as I mentioned above
2. Unlike any other implicit/explicit pairs, "argument construction operator" uses _explicit_ conversion method (`*` uses `#to_ary` and `**` uses `#to_hash`)
3. There is no means/helpers/practices to draw explicit method from implicit (though implicit is easier to define)

I believe that (2) is what we'll just need to live with, but both (1) and (3) could be solved with introducing core module `Callable` (akin to `Enumerable` and `Comparable`), defined, let's say, like this:
```ruby
module Callable
  def to_proc
    proc { |*a, &b| call(*a, &b) }
  end
end
```
That's not so much "non-trivial code", as "atomic declaration of statement": "this thing is callable; Proc and Method are callable, but you can define your own; proc composition composes any callable objects".

Usage in some client code:
```ruby
class SetStatus < BusinessAction
  def self.call(task, status)
    new(task, status).validate.call # ...or something
  end

  extend Callable
end

tasks_and_statuses.each(&SetStatus)
```

WDYT?

----------------------------------------
Bug #15428: Refactor Proc#>> and #<<
https://bugs.ruby-lang.org/issues/15428#change-76265

* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: 
* Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN
----------------------------------------
#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:

```ruby
# 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. 



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>