[#90865] [Ruby trunk Bug#15499] Breaking behavior on ruby 2.6: rb_thread_call_without_gvl doesn't invoke unblock_function when used on the main thread — apolcyn@...
Issue #15499 has been reported by apolcyn (alex polcyn).
3 messages
2019/01/03
[#90877] [Ruby trunk Bug#15499] Breaking behavior on ruby 2.6: rb_thread_call_without_gvl doesn't invoke unblock_function when used on the main thread — apolcyn@...
Issue #15499 has been updated by apolcyn (alex polcyn).
3 messages
2019/01/03
[#90895] Re: [ruby-alerts:11680] failure alert on trunk-mjit@silicon-docker (NG (r66707)) — Eric Wong <normalperson@...>
ko1c-failure@atdot.net wrote:
4 messages
2019/01/05
[#90896] Re: [ruby-alerts:11680] failure alert on trunk-mjit@silicon-docker (NG (r66707))
— Takashi Kokubun <takashikkbn@...>
2019/01/05
Thanks to explain that.
[#91200] [Ruby trunk Feature#15553] Addrinfo.getaddrinfo supports timeout — glass.saga@...
Issue #15553 has been reported by Glass_saga (Masaki Matsushita).
4 messages
2019/01/21
[#91289] Re: [Ruby trunk Feature#15553] Addrinfo.getaddrinfo supports timeout
— Eric Wong <normalperson@...>
2019/01/26
glass.saga@gmail.com wrote:
[ruby-core:91045] [Ruby trunk Feature#15301] Symbol#call, returning method bound with arguments
From:
zverok.offline@...
Date:
2019-01-12 13:59:32 UTC
List:
ruby-core #91045
Issue #15301 has been updated by zverok (Victor Shepelev).
In the light of discussions here: https://bugs.ruby-lang.org/issues/15428#change-76265 (TL;DR: `#call` is "implicit Proc conversion") I retract this proposal.
Please close.
----------------------------------------
Feature #15301: Symbol#call, returning method bound with arguments
https://bugs.ruby-lang.org/issues/15301#change-76266
* 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>