[#74190] [Ruby trunk Feature#12134] Comparison between `true` and `false` — duerst@...
Issue #12134 has been updated by Martin D端rst.
3 messages
2016/03/07
[#74269] Type systems for Ruby — Rob Blanco <ml@...>
Dear ruby-core,
5 messages
2016/03/10
[#74395] [Ruby trunk Feature#12142] Hash tables with open addressing — shyouhei@...
Issue #12142 has been updated by Shyouhei Urabe.
3 messages
2016/03/17
[ruby-core:74291] [Ruby trunk Feature#12141] send and __send__
From:
Ruby-Lang@...
Date:
2016-03-14 01:32:11 UTC
List:
ruby-core #74291
Issue #12141 has been updated by J旦rg W Mittag. Martin D端rst wrote: > I agree with Yusuke. The name `__send__` is chosen explicitly to show that this is an 'internal' method with special status. Also, the messaging metaphor is at the core of Smalltalk-style OOP. And the very heart of this metaphor is precisely that you do *not* "call" or "invoke" methods, but rather send messages to objects which then may or may not invoke a method *for you* in response to that message, and that method may or may not have the same name as the message. Or, they may forward the message to somewhere else. Or, they may ignore the message. ---------------------------------------- Feature #12141: send and __send__ https://bugs.ruby-lang.org/issues/12141#change-57413 * Author: Sebastian Herm * Status: Open * Priority: Normal * Assignee: ---------------------------------------- Hi guys ! We have this concept of sending messages to objects with `Object#send`, and that's fine, but often a child class defines its own send method, so that's why we have this ugly `Object#__send__` hack. So, I suggest dropping `Object#__send__` and aliasing `Object#send` to `Object#invoke` instead, which seems to me as a better evocative method name. Good or bad idea ? Thanks ! -- 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>