Forum: Ruby variables to call methods in ruby...

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.
44174dce86ebe8a2a0e456d27f82a8be?d=identicon&s=25 Harnish (Guest)
on 2007-06-25 00:43
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
D5846a004fa29b8c5478bedf3dfd75c3?d=identicon&s=25 Adam Bozanich (Guest)
on 2007-06-25 00:49
(Received via mailing list)
On 6/24/07, Harnish <harnishb@amazon.com> wrote:
>
> testfunc; is it possible for me to invoke Test.func using variable
> testfunc?  If yes, how?  Any ideas, greatly appreciated.


You can use send:

testfunc = "func"

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

Test.send testfunc
3afd3e5e05dc9310c89aa5762cc8dd1d?d=identicon&s=25 Tim Hunter (Guest)
on 2007-06-25 00:50
(Received via mailing list)
Harnish wrote:
> 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)
Bc8e3e2f7acb3a7d93c10e235dc0b4e1?d=identicon&s=25 yermej@gmail.com (Guest)
on 2007-06-25 01:51
(Received via mailing list)
On Jun 24, 5:48 pm, Tim Hunter <TimHun...@nc.rr.com> wrote:
> Harnish wrote:
> > 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)

I've always used it without the underscores:

var = "func"
obj.send "func", an_arg
509e15b158eaac5ab3a5332a3f89d4a7?d=identicon&s=25 Peter Cooper (Guest)
on 2007-06-25 01:58
(Received via mailing list)
On 6/25/07, yermej@gmail.com <yermej@gmail.com> wrote:
>
> 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/
D5846a004fa29b8c5478bedf3dfd75c3?d=identicon&s=25 Adam Bozanich (Guest)
on 2007-06-25 02:46
(Received via mailing list)
On 6/24/07, Peter Cooper <peter@peterc.org> wrote:
> > >
> 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


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?

And of course in the simple proxy example, using __send__ doesn't really
make a difference.

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

class Proxy < BlankSlate
    def initialize obj
        @obj = obj
    end
    def method_missing msg , *args , &block
        puts "proxying #{msg}..."
        @obj.send msg , *args , &block
    end
end

str = Proxy.new "hello"
puts ( str.send(:size) == str.__send__(:size))  # => true

-Adam
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2007-06-25 03:42
(Received via mailing list)
Hi --

On Mon, 25 Jun 2007, Adam Bozanich wrote:

> 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
D5846a004fa29b8c5478bedf3dfd75c3?d=identicon&s=25 Adam Bozanich (Guest)
on 2007-06-25 04:11
(Received via mailing list)
On 6/24/07, dblack@wobblini.net <dblack@wobblini.net> wrote:
>
> 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.


Doh! Good call.  Time to kick my double underscore aversion ;)

-Adam
509e15b158eaac5ab3a5332a3f89d4a7?d=identicon&s=25 Peter Cooper (Guest)
on 2007-06-25 04:13
(Received via mailing list)
On 6/25/07, dblack@wobblini.net <dblack@wobblini.net> wrote:
> On Mon, 25 Jun 2007, Adam Bozanich wrote:
> > 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:

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/
This topic is locked and can not be replied to.