From: Intransition <transfire@...>
Date: 2010-06-18T08:21:31+09:00
Subject: Re: method interface - hash argument vs. named parameters

On Jun 17, 11:25 am, Josh Cheek <josh.ch...@gmail.com> wrote:

> > Is there any way? Or am I stuck?
>
> I would expect stuck, because the difference seems nothing more than visual.
> (ie if the options hash was assigned to a var, rather than created within
> the arg list, then the last two would be exactly the same) though it does
> seem unusual that there is not a method like options_given? the way there is
> a block_given?
>
> I suppose if this method interface is absolutely necessary, then a hack you
> might be able to get away with would be to check the keys to see if they
> match up with your options. But I would be embarrassed to show anyone such a
> solution ;)
>
> Something to consider, though, whatever param the hash is an arg for, is
> optional (ie omitted in your third invocation). So perhaps it would fit
> better into the options hash, which you could then extract it from, inside
> the method:
>
> def foo( options = Hash.new )
>   the_hash = options.delete(:the_hash) { Hash.new }
>   [ the_hash , options ]
> end
>
> hash = Hash[*1..4]
> val = :val
>
> foo( :the_hash => hash , :opt => val )  # => [{1=>2, 3=>4}, {:opt=>:val}]
> foo( :the_hash => hash )                # => [{1=>2, 3=>4}, {}]
> foo( :opt => val )                      # => [{}, {:opt=>:val}]

Yep. That's what I thought. Appreciate the suggestion. In my case I've
decided I'll just have to do without the options hash.

I was hoping Ruby 1.9 at least would have had this licked. Early on
there was talk of named parameters as:

  def foo(hash=nil, **opts)

But it never came to pass.

Thanks.