From: ara.t.howard@...
Date: 2006-04-25T13:22:45+09:00
Subject: Re: [RCR] Hash#getopt

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.

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
-- 
be kind whenever possible... it is always possible.
- h.h. the 14th dali lama