Hash#getopt


#1

at this point calls of the form

some_method arg, “key” => “value”

or

some_method arg, :key=>:value

are idiomatic ruby. let’s just support it directly and be done with it:

 harp:~ > cat a.rb
 class ::Hash
   def getopt opt, default = nil
     keys = opt.respond_to?('each') ? opt : [opt]
     keys.each do |key, *ignored|
       return self[key] if self.has_key? key
       key = "#{ key }"
       return self[key] if self.has_key? key
       key = key.intern
       return self[key] if self.has_key? key
     end
     return default
   end
 end

 opts = {'k' => 42}
   p opts.getopt('k')
   p opts.getopt(:k)

 opts = {:k => 42}
   p opts.getopt('k')
   p opts.getopt(:k)

 opts = {'K' => 42}
   p opts.getopt('k', opts.getopt('K'))
   p opts.getopt(:k, opts.getopt(:K))
   p opts.getopt(%w( k K ))

 opts = {:K => 42}
   p opts.getopt('k', opts.getopt('K'))
   p opts.getopt(:k, opts.getopt(:K))
   p opts.getopt(%w( k K ))



 harp:~ > ruby a.rb
 42
 42
 42
 42
 42
 42
 42
 42
 42
 42

regards.

-a


#2

Hi –

On Tue, 25 Apr 2006, removed_email_address@domain.invalid wrote:

at this point calls of the form

some_method arg, “key” => “value”

or

some_method arg, :key=>:value

are idiomatic ruby. let’s just support it directly and be done with it:

Can you editorialize a little more? :slight_smile: I’m not clear on the
connection between the above and the below. Are you mainly interested
in having hashes that don’t differentiate between string and symbol
keys?

David


David A. Black (removed_email_address@domain.invalid)
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

“Ruby for Rails” PDF now on sale! http://www.manning.com/black
Paper version coming in early May!


#3

On Tue, 25 Apr 2006 removed_email_address@domain.invalid wrote:

some_method arg, :key=>:value

are idiomatic ruby. let’s just support it directly and be done with it:

Can you editorialize a little more? :slight_smile: I’m not clear on the
connection between the above and the below. Are you mainly interested
in having hashes that don’t differentiate between string and symbol
keys?

yes, but only for the getopt method. mainly i’m campaigning for a
Hash#getopt method to support people writing friendly apis that can be
used
like this

spawn cmd, :stdin => buf

or

spawn cmd, ‘stdin’ => buf

given a def like

def spawn cmd, opts = {}
stdin = opts.getopt :stdin

end

i think that when getting and option from a hash, and only when getting
an
option from a hash, we should be able to use strings or symbols and
provide a
default value. note that we cannot use short-circuit operator for
default
here since

def some_method arg, opts = {}
quiet = opts.getopt(:quiet) || true
end

would fail with

some_method 42, :quiet => false

and hence Hash#getopt also requires the optional ‘default’ param so
useage
may, instead, be

def some_method arg, opts = {}
quiet = opts.getopt(:quiet, true)
end

followed by

some_method 42, :quiet => false

and this then behaves correctly.

make more sense?

regards.

-a


#4

Hi –

On Tue, 25 Apr 2006, removed_email_address@domain.invalid wrote:

end

followed by

some_method 42, :quiet => false

and this then behaves correctly.

make more sense?

Yes. I’m not sure how I’ll vote when it appears on RCRchive :slight_smile: (I’m
not big on the symbol <=> string indifference thing, though I can see
where having a particular access method that uses it could be useful.)

David


David A. Black (removed_email_address@domain.invalid)
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

“Ruby for Rails” PDF now on sale! http://www.manning.com/black
Paper version coming in early May!


#5

On Tue, 25 Apr 2006, Brian M. wrote:

Brian.

i agree. however, consider that they are really two orthogonal ideas:

 harp:~ > cat a.rb
 class ::Hash
   def getopt opt, default = nil
     keys = opt.respond_to?('each') ? opt : [opt]
     keys.each do |key, *ignored|
       return self[key] if self.has_key? key
       key = "#{ key }"
       return self[key] if self.has_key? key
       key = key.intern
       return self[key] if self.has_key? key
     end
     return default
   end
 end

 require 'yaml'

 config = YAML::load <<-conf

   host : codeforpeople.com
   port : 80
   path : /lib/ruby

 conf

 p config.getopt(:host)
 p config.getopt(:protocol, 'http')



 harp:~ > ruby a.rb
 "codeforpeople.com"
 "http"

there are often times where a hash is used in ruby as a bundle of
options/attributes, in these cases it’s often useful to offer
symbol/string
indifferent access. and, even if keyword arguments are supported, i’m
sure
hash-style interfaces will remain for quite a while - there are simply
too many
of them out there already.

cheers.

-a


#6

removed_email_address@domain.invalid wrote:

make more sense?

Yes. I’m not sure how I’ll vote when it appears on RCRchive :slight_smile: (I’m
not big on the symbol <=> string indifference thing, though I can see
where having a particular access method that uses it could be useful.)

David, can you elaborate a little more. I’m interested in why you are
“not big of the symbol <=> string indifference thing”.


#7

On 4/24/06, removed_email_address@domain.invalid removed_email_address@domain.invalid wrote:

end

followed by

some_method 42, :quiet => false

and this then behaves correctly.

make more sense?

I think it makes sense, but we need to consider that, as far as 2.0 is
concerned, there will probably be other solutions/options. I am
talking about keyword arguments. I may have been one in the minority
but I liked Matz’s idea for keyword arguments.

With this sort of future addition one could question the need of
adding this to Hash. I can’t say I am on either side yet. I think it
might be time to evaluate what is really useful about hash arguments
that keyword arguments won’t handle (nicely). It might come down to
TIMTOWTDI or backwards compatibility.

Brian.