From: Mike Depot <mdepot@...>
Date: 2002-06-14T05:06:15+09:00
Subject: Named parameter passing - Re: procs and blocks

I would like to see Ruby support better named parameter passing as well.  I
guess the hash coersion is nice, but I long for something more...  I really
think there is an oppourtunity to let Ruby do something that other languages
fall sort on, and that could be very good for the future of the language.

IMHO using named parameters gives you some great advantages in a number of
situations. At the moment, these stand out in my mind:
1) The ability to pass parameters to a function in any arbitrary order.
2) The ability to arbitrarily add parameters and change which parameters are
required vs optional without being forced to change the calling interface to
the function itself. (Great for reverse compatibility of public interfaces!)

The problem with most languages (at least those I've worked with) is that
named parameter passing is not supported as part of the language itself.
Typically, from the perspective of the language, you just pass a single
value to the function, which happens to be some sort of hash structure or
object containing the named parameter list.  It then falls on the programmer
to manually write code to:
1) Check that the parameters which are required were actually passed.
2) Set defaults values for parameters that were optional.
3) Complain about any invalid parameters that were passed

With the more traditional parameter passing scheme, the parser itself checks
all those things for you.  It assignes passed values to the variables
defined in the function definition, it can warn you if too many or not
enough arguments were passed, and the parser itself can set defaults for
variables that are optional (assuming the case where you define defaults in
your function definition).  The parser is able to do all this because the
syntax itself allows for the required information to be included in the
function definition itself.

It would be great if those same abilites existed for values passed in a
named parameter fashin.  That is syntax existed that would allow the
function definition itself to contain:
1) What parameters names are valid
2) Of those that are valid, which are required vs optional
3) What to use for defaults for optional parameters

With this info in the function definition, you could get all the advantages
of using named parameters, yet the parser itself could take care of all the
validation that now has to be checked manually in code.

At one point I read something that said Matz was thinking of building
support for named parameter passing into the next version of the language.
( I admit that was quite a while ago.)  Is something like the above possible
without breaking reverse compatibility?  I don't know, but sure would like
to see a discussion on it...

Mike Depot

> You can simulate named parameters with a hash:
>
> def foo(params)
>   p params[:rar]
>   p params[:blah]
> end
>
> foo(:blah => "hello", :rar => "meow")