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
Hi –
On Tue, 25 Apr 2006, [email protected] 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? 
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 ([email protected])
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)
“Ruby for Rails” PDF now on sale! Ruby for Rails
Paper version coming in early May!
On Tue, 25 Apr 2006 [email protected] 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? 
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
Hi –
On Tue, 25 Apr 2006, [email protected] 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 (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 ([email protected])
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)
“Ruby for Rails” PDF now on sale! Ruby for Rails
Paper version coming in early May!
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
[email protected] wrote:
make more sense?
Yes. I’m not sure how I’ll vote when it appears on RCRchive (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”.
On 4/24/06, [email protected] [email protected] 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.