From: Brian Mitchell <binary42@...>
Date: 2006-04-25T13:11:43+09:00
Subject: Re: [RCR] Hash#getopt

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