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
regards.
-a
···
--
be kind whenever possible... it is always possible.
- h.h. the 14th dali lama
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
···
On Tue, 25 Apr 2006 dblack@wobblini.net wrote:
Hi --
On Tue, 25 Apr 2006, ara.t.howard@noaa.gov 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?
--
be kind whenever possible... it is always possible.
- h.h. the 14th dali lama
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.
···
On 4/24/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
On Tue, 25 Apr 2006 dblack@wobblini.net wrote:
> 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?
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
···
On Tue, 25 Apr 2006, Brian Mitchell wrote:
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.
--
be kind whenever possible... it is always possible.
- h.h. the 14th dali lama
dblack@wobblini.net 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".
···
--
John Long
http://wiseheartdesign.com