From: Steve Tu Date: 2013-02-03T17:45:23+09:00 Subject: Re: Novice: self, @self.respond_to? and dynamically built methods unknown wrote in post #1094776: > Am 01.02.2013 16:06, schrieb Steve Tu: > >> The code I have is now split into separate files that are 'load' or >> 'require'd. The argument test file contains: >> #----------------------------------------------------------------------- >> # F O R M A L A R G U M E N T S >> #----------------------------------------------------------------------- >> def arguments_test >> require 'getoptlong' > > I like optparse. > >> >> # The parameters can be in any order >> STDOUT.puts "Arguments "+ARGV.length.to_s > > puts uses stdout by default, so you can just use `puts'. > >> [ "--subject", "-s", GetoptLong::REQUIRED_ARGUMENT ], >> end >> >> STDOUT.puts "(#{self}) - (#{self.to_s}) Supports (#{self.methods})" > > #{self} sends to_s implicitly, so #{self} and #{self.to_s} are the same > >> `zenity --info --title="Arguments ... " --text="Args: >> What I now end up with is the 'private' respond_to? test working - which >> is one point I don't understand (ie what determines a method's >> visibility - I thought it had to be explicitly defined or was assumed as >> public?). > > Seems 'global' methods behave differently, they are private methods > of `Object', see > http://stackoverflow.com/questions/8799704/are-ruby-imported-methods-always-private > >> That then lead onto the question re how to determine the >> footprint of the method being called, as the code above works if the >> method passed accepts a single parameter. If the method accepts o >> parameters then the code fails anyway - and hence the question re >> whether it is simply then better to just attempt the method call and >> trap the errors thrown, rather than trying to see if the method is >> supported in the first place. >> Am I making any sense at all? > > You could use an optional argument hash. > > > Still, this approach seems a bit strange to me. > Ever thought about defining classes? I am following a tutorial, so am picking up each example as is. I am then trying to modify those examples (on a limited basis), just to make sure I understand the lesson and what it implies. I may revisit older examples if I see a new facility that I think applies - as here, where I thought I could bypass my menu and use the passed arguments to dynamically call the tutorial lesson. I just get a bit lost as to Ruby's built in methods and what they're meant to do (I can see WHAT they do, but the implication of when/where/why sometimes loses me). Here, for example, you can see if a method is available by respond_to? and eval and send will then execute a 'prepared' string as a method. But if I can't tell what the footprint is of the method what is the point in being able to dynamically execute a method (ie I could end up calling a methods as blah() when it should be called as blah(int, string, int))? What then is dynamic method execution for, if I can't tell how the method is to be called in detail? Thanks for the info on 'global' methods by the way - that explains the why I was seeing my 'respond_to?' fail - and also why I thought it worked when I called it as respond_to?("hashes_test","1"). -- Posted via http://www.ruby-forum.com/.