--- Daniel Schierbeck <daniel.schierbeck / gmail.com> wrote:

> Furthermore, the named arguments are gathered in a hash in
> which the 
> keys are symbols.
> 
>    keys[:key] -> value

I don't think this should be an assumption about how named
arguments work (unless you are talking about the final **keys
arg).  The easiest initial implementation may be to use hashes
to pass around named arguments, but as we get better VM's and
compilers, that could change.

The main thing I don't like about the current proposal (what
matz presented at rubyconf) is that the *args (remaining
positional args) also contains the named arguments.  So this:

def foo(a,b=1,*args,c:,d:2,**keys) ... end

called like this:

foo("a","b","x","y",c:"c",e:"e")

gives:

a = "a"
b = "b"
args = ["x","y",{ :c => "c", :d => 2, :e => "e" }]
c = "c"
d = 2
keys = { :e => "e" }

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.

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}

I would rather see it be the first interpretation and if you
wanted the second, you'd "splat" the hash:

foo("a",**{:x => 1,:y => 2})

which would be the same as:

foo("a", x : 1, y : 2)


I think whether we have something sydney/python like where
positional arguments can automatically be named or whether
there is a clear distinction between positional/named like
lisp, it is OK.  Another language comparison to make is just
the shell command-line.  One the command-line named arguments
are effectively the "options" and positional are the rest.  On
that note, another option would be to specify the named
arguments like command-line options:

def foo(a, b=1, --c=2, --*keys) ... end

foo("a", --c="c", --x=1, --y=2)

Or simply "-" instead of "--" if it could be handled in the
parser (could be confused with a unary - at first).  But, I'm
not terribly concerned with syntax.

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.

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.




	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com