From: Daniel Berger <Daniel.Berger@...>
Date: 2006-03-03T03:11:31+09:00
Subject: Re: Confusion Over Keyword Arguments

Yukihiro Matsumoto wrote:
> Hi,
> 
> In message "Re: Confusion Over Keyword Arguments"
>     on Fri, 3 Mar 2006 02:30:34 +0900, Daniel Berger <Daniel.Berger@qwest.com> writes:
> 
> |>  foo(1, foo:3)     # (a=1, b={:foo=>3}) or (a=1,b=0,c=[{:foo=>3}])?
> |
> |Error.  There's no 'foo' parameter.  Passing a literal hash would require {}.
> 
> I'm not sure what you meant by "literal hash".  Do you mean foo:3 is
> not legal since you don't have an argument with a name "foo"?
> 
> Have you changed your mind since the blog entry at
> http://djberg96.livejournal.com/50162.html?  For you have written
> 
> 
>>foo(1, 2, foo:4, bar:5) # a=1, b=2, c=[{'foo'=>4, 'bar'=>5}]
>>foo(1, 2, 8, baz:5)     # a=1, b=2, c=[8, {'baz'=>5}]
> 
> 
> in it.  foo:4 etc. seems like non-literal hash.

Oops - I didn't notice you had declared it "*c" instead of "c".  My blog entry 
is the expected behavior.

> |>  args = [1, {:b=>2, foo=>5}]
> |>  foo(*args)        # (a=1,b={:b=>2, foo=>5}) or (a=1,b=2,c=[{:foo=>5}])?
> |
> |a = 1, b = {:b=>2, foo=>5}, since you've passed a literal hash.
> 
> This means that you cannot accept
> 
>  (a) a keyword argument that is possibly accepted by the superclass's
>      method, without knowing their names

I'm not sure I follow.  How would you know the keyword arguments without 
knowing their names?  Or are we getting into keyword discovery here?

>  (b) arbitrary keywords that can be passed to other methods

What do you mean by 'arbitrary keywords'?

> Right? If so, (a) means you need to have exact argument information
> about a superclass method, which may not be available for mix-in
> modules;

I'm afraid I'm not following.

(b) means there's no way to convert keyword arguments to a
> hash.

Are you talking internals, or by the user?

Well, anyway, I think this has all been gone over before.  I probably should 
have just kept my mouth shut.

Dan