From: dblack@...
Date: 2006-04-25T13:00:33+09:00
Subject: Re: [RCR] Hash#getopt

Hi --

On Tue, 25 Apr 2006, ara.t.howard@noaa.gov wrote:

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

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 (dblack@wobblini.net)
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!