Feature #12141
open
Added by hermes128 (Sebastian Herm) over 8 years ago.
Updated over 8 years ago.
Description
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 !
Sorry, hard time editing/formating my post !
:-(
But I hope you understand what I mean !
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.
Hmm the second send that appears in bold is a __send__
- it seems
as if rubymine interpretes this as bold, sorry.
Thanks for your feedback. :-)
I agree, it's a minor (cosmetic) issue. For example, Rails uses __send__
only 17 times in its huge codebase. :-)
I don't suggest removing send
, but just replacing __send__
with invoke
to have a better named alias (yes, maybe for Ruby 3.0 ?)
- Description updated (diff)
I agree with Yusuke. The name __send__
is chosen explicitly to show that this is an 'internal' method with special status.
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.
Also available in: Atom
PDF
Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0