[#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:74127] [Ruby trunk Feature#12141] send and __send__
From:
shevegen@...
Date:
2016-03-04 07:02:31 UTC
List:
ruby-core #74127
Issue #12141 has been updated by Robert A. Heiler. I think this could only be done in ruby 3.x But I believe that .send will remain because it is super short. :) In the later ruby days, people added .public_send but .send is still so much shorter to use and write; .invoke would also be longer to type. :D The statement that classes often define their own .send is not true though. I think for 5000 ruby classes that I may have written so far in 12 years or so, I could not recall any more instance than one or two at max where I would need a custom .send nor __send__ - it seems very specialized and thus I don't think this warrants a change of the name .send() - but that is of course just my own personal opinion here. ---------------------------------------- Feature #12141: send and __send__ https://bugs.ruby-lang.org/issues/12141#change-57272 * 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>