Forum: Ruby send vs. dot notation

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Giles B. (Guest)
on 2006-05-19 09:21
(Received via mailing list)
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?
Eli B. (Guest)
on 2006-05-19 09:32
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
Uncutstone W. (Guest)
on 2006-05-19 09:45
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.
Pit C. (Guest)
on 2006-05-19 11:44
(Received via mailing list)
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
Ross B. (Guest)
on 2006-05-19 11:51
(Received via mailing list)
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...
Giles B. (Guest)
on 2006-05-19 22:58
(Received via mailing list)
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
This topic is locked and can not be replied to.