What’s a good reason to use send() instead of a dot to send a message?
Is it for situations where you know you’re going to want to send an
object a message, but you don’t know what that message is until
runtime?
Giles B. wrote:
What’s a good reason to use send() instead of a dot to send a message?
Is it for situations where you know you’re going to want to send an
object a message, but you don’t know what that message is until
runtime?
Yes, this is a good example. Since Ruby has no real concept of “compile
time”, we can refer to it as “coding time”. So:
obj.do_stuff(args)
Is only possible when you know at “coding time” that ‘do_stuff’ is the
method you want to call on obj. If you don’t know it, and it will become
known only during “run time”, you can do:
obj.send(method_name, args)
Where ‘method_name’ stores the name of the method
Giles B. schrieb:
What’s a good reason to use send() instead of a dot to send a message?
Is it for situations where you know you’re going to want to send an
object a message, but you don’t know what that message is until
runtime?
Giles, as others have noted, this is the main reason. Another one has
been to call private methods of an object:
class C
private
def secret_method
puts “in secret_method”
end
end
o = C.new
o.secret_method rescue puts $!
=> private method `secret_method’ called for #<C:0x2ba2790>
o.send :secret_method
=> in secret_method
So you will find usages of “send” where the method is known at “coding
time”. But note that this behaviour of “send” will change in future
versions of Ruby. In order to call private methods, better use this:
o.instance_eval { secret_method }
=> in secret_method
Regards,
Pit
On Fri, 2006-05-19 at 16:43 +0900, Pit C. wrote:
Giles B. schrieb:
What’s a good reason to use send() instead of a dot to send a message?
Is it for situations where you know you’re going to want to send an
object a message, but you don’t know what that message is until
runtime?Giles, as others have noted, this is the main reason. Another one has
been to call private methods of an object […]
Also, I’ve seen it used before to do things like:
class C
define_method(:“wierd method with-illegal-chars”) { puts “call me” }
end
C.new.send(:“wierd method with-illegal-chars”)
call me
Can’t remember exactly why, I think it was part of a memoize type thing,
to store stuff in methods without clashing or something. In any event it
seems like a bad idea to me, but there you go…
Many thanks for all the helpful replies…the memoize and
runtime/code-time uses make a good deal of sense to me. Calling
private methods from outside an object seems a bit naughty but it’s
certainly a nicely illustrative example.
–
Giles B.
http://www.gilesgoatboy.org
Giles B. wrote:
What’s a good reason to use send() instead of a dot to send a message?
Is it for situations where you know you’re going to want to send an
object a message, but you don’t know what that message is until
runtime?
I think send is one of the key features of Ruby. It is a core underneath
mechanism. It is widely used.
For example, I think it is used in implementation of DRb. Whenever a DRb
server gets a call from a client, it gets the method name and other
things,so it send message to the server object.
IMHO, anywhere you want a level of indirection of function call, you may
consider using send.