From: Yukihiro Matsumoto <matz@...>
Date: 2005-10-24T08:34:53+09:00
Subject: Re: A comparison by example of keyword argument styles

Hi,

In message "Re: A comparison by example of keyword argument styles"
    on Mon, 24 Oct 2005 05:50:39 +0900, Eric Mahurin <eric_mahurin@yahoo.com> writes:

|What use is it to have the named arguments appear twice?  I
|understand the need if you don't have named arguments in the
|definition (compatibility), but as soon as named arguments are
|specified, it seems to serve no purpose.

It's for method delegation.  Currently we do 

  def foo(*args)
    bar(*args)
  end

for method delegation.  Under my proposal, this delegation would still
work fine, since we have named arguments appear twice, otherwise we
must change the code as

  def foo(*args, **keys)
    bar(*args, **keys)
  end

everywhere, to just do delegation.

|Also, like we have array splatting when you call a method, I
|think hash splatting would also be useful.  matz said that
|hashes would be automatically splatted if they were the last
|argument, but this results in ambiguity:
|
|def foo(a,b={},c:2,**keys) ... end
|
|foo("a",{:x => 1,:y => 2})
|
|Does the above result in:
|
|a = "a", b = {:x => 1,:y => 2}, c = 2, keys = {}
|
|or:
|
|a = "a", b = {}, c = 2, keys = {:x => 1,:y => 2}

The former.  Keyword argument uses the last remaining hash.

|I'm hoping that we have enough reflection for these named
|arguments like #arity.  I'm thinking that with named arguments
|a potential simple application would be as a spec for handling
|command-line options (named arguments).  I'd like to see all of
|the keywords and defaults accessible from Proc/Method objects. 
|It'd be nice to have access to defaults of positional args
|while wer'e asking.

Accepting keywords should be obtained from some kind of reflection
API, although the API is not fixed yet.  But I'm not sure default
values can be accessed since they are arbitrary expression, and we
have no good way to represent pre-evaluated expression in Ruby (unlike
in Lisp, where we can use S expression).

|Since Ruby 2 will also be completely redoing how
|multiple-values are handled, why not also consider being able
|to name your return values?  If a method returns a bunch of
|attributes, it would be nice for the caller to be able to pick
|what they want.

I have no good idea of multiple value binding for named values
(i.e. syntax).  Do you?

							matz.