variables to call methods in ruby...

[Harnish]

Hi,

This is Harnish. I was just wondering if I could call methods using
variables?

As for example:

-----------------
testfunc = "func"

class Test
def self.func
puts "hello there...!"
end
end

Test.<testfunc>
-----------------

Essentially I want to call Test.func; but "func" lies in the variable
testfunc; is it possible for me to invoke Test.func using variable
testfunc? If yes, how? Any ideas, greatly appreciated.

Regards,
Harnish

 

[Tim Hunter]

Essentially I want to call Test.func; but "func" lies in the variable
testfunc; is it possible for me to invoke Test.func using variable
testfunc? If yes, how? Any ideas, greatly appreciated.

Check out the "__send__" method:

var = "func"
obj.__send__(var, args)

 

[yermej]

Check out the "__send__" method:

var = "func"
obj.__send__(var, args)

I've always used it without the underscores:

var = "func"
obj.send "func", an_arg

 

[Peter Cooper]

I've always used it without the underscores:

You can, but in case you're wondering the whys and wherefores of all
this.. it's possible to easily change the "send" method on a class
with anyone noticing.. this could cause "Bad Things"(tm) to happen.

It's possible to redefine __send__ too, but a warning is given and
it's generally considered bad form to redefine, delete, or otherwise
modify methods using the __x__ naming convention. You'll notice
classes like BlankSlate (
http://onestepback.org/index.cgi/Tech/Ruby/BlankSlate.rdoc ) take this
into account:

class BlankSlate
instance_methods.each { |m| undef_method m unless m =~ /^__/ }
end

Cheers,
Peter Cooper
http://www.rubyinside.com/

 

[dblack]

Hi --

I see your point, it just seems like using __send__ breaks encapsulation.
If a class is re-defining send for some reason, the user probably shouldn't
have to know/care about it.

I suppose if the proxy is adding some extra methods ( is_proxy?() ) then
__send__ would be a better choice. But then again, unless you add that to
everything, you'd have to use a respond_to? -- starting to get pretty ugly.
Can you think of any cases that show why always using __send__ is both
necessary and clean?

It's really more for cases where 'send' is used for something totally
different:

class Message
def send
Net::SMTP.open ....
...
end
end

If someone wants to send (in the original sense) a message (in the
original sense to a Message object, they'll end up calling the new
send.


David

--
* Books:
RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242)
RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
& consulting: Ruby Power and Light, LLC (http://www.rubypal.com)

 

[Peter Cooper]

It's really more for cases where 'send' is used for something totally
different:

David illustrates it better than I did, but the basic "rule" I tend to
take away is that "__send__" is, effectively, guaranteed to do what I
think it will (I'll see a warning if it doesn't).. whereas "send"
might not. Such concerns aren't that important if you're working on
classes you're familiar with, however, or if methods aren't being
called on dynamically-chosen classes you have little control over.

Cheers,
Peter Cooper
http://www.rubyinside.com/