Project

General

Profile

Actions

Feature #15301

closed

Symbol#call, returning method bound with arguments

Added by zverok (Victor Shepelev) about 4 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
[ruby-core:89783]

Description

In one Reddit discussion I've got stuck with this simple, yet seemingly powerful idea, not sure if it was discussed anytime previously (can't find on the bug tracker, but maybe I am just bad at searching):

class Symbol
  def call(*args, &block)
    proc { |x| x.send(self, *args, &block) }
  end
end

[10, 20, 30].map &:modulo.(3) # => [1, 2, 0]
[[1, -2], [-3, -4]].map(&:map.(&:abs)) # => [[1, 2], [3, 4]]
[1, 2, 3, 4].map &:**.(2) # => [1, 4, 9, 16]

I understand and respect core team's reluctance for adding new methods to core classes, but from the top of my head I can't invent incredibly bad consequences (there, of course, could be some codebases that defined their own Symbol#call in a different way, but I don't estimate the probability as super-high; and the same could be said almost for any new method).

On the other hand, resulting code seems pretty nice, "Rubyish", explainable and mostly unambiguous.

Would like to hear other's opinions.

PS: One obvious objection could be that it is almost a de-facto standard to have any object's #to_proc to return proc doing exactly the same what the #call does (if the object happen to have both). It is unfortunate, but I believe the people will use to it, considering the possible gains. And, anyway, that's only "de-facto" rule, not the language standard :)


Related issues 1 (1 open0 closed)

Is duplicate of Ruby master - Feature #12115: Add Symbol#call to allow to_proc shorthand with argumentsOpenActions
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0