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


> I understand and respect core team's reluctance for adding new methods to core classes

Ultimately it is up to matz, but I believe it is not so much reluctance, but more the
general question "will this be of benefit to many people".

> [...] resulting code seems pretty nice, "Rubyish", explainable and mostly unambiguous.

I think this depends a lot on the particular style used by a ruby user. For example, to
me personally, a lot of the rails code is mysterious. To rails users rails is probably
simple to understand and "normal".

What I personally found with method_missing is that it can become very confusing. It's
great that we have method_missing but I am not sure that every use case of method_missing
is great.

Note that this is not a negative or positive opinion about your suggestion - I actually
am not even sure what your suggestion is about. :D

I think ".(2)" is very unusual though.

There is also a bit of a minor strangeness in the examples you gave, in that line:

    [[1, -2], [-3, -4]].map(&:map.(&:abs)) # => [[1, 2], [3, 4]]

I think using .map twice like that is a bit odd. Matz likes DRI aka to not repeat
yourself (in ruby code) if possible. But again, that's mostly my opinion here; I 
gladly leave that discussion to people who have a stronger opinion either way.

PS: Actually, I think this may require a comment by matz anyway, since I am not
sure it fits with how he sees Symbols e. g. having them respond to #call. I 
understand that Symbols have changed a little bit over the years, e. g. got a
bit more String-like behaviour, but I am not sure if they are or should be
call-able? But again, I am not really invested into this idea, so I'll just
peace out. Please just view this here as suggestion for further comments rather
than anything pro or con. :)

----------------------------------------
Feature #15301: Symbol#call, returning method bound with arguments
https://bugs.ruby-lang.org/issues/15301#change-74848

* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
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):

```ruby
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 :) 



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

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