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/.