Ok, last recommendation for named parameters was:

obj.my_method( height: 10, width: 20, name: "foo" )

The problem I've got with this is that you can alter the parameter order and
I suspect that this calling convention incurs extra runtime cost.

I was having look at another language called ElastiC, which is a pretty cool
language.  As far as I can tell its named method calls are similar to
Smalltalks and especially similar (identical?) to Objective-C.

[obj height: 20 width: 40 name: "foo" ]

But the interesting thing to note is that there is no method name specified.
The method is selected based on the argument names.

It's like having a method defined as:

def height: width: name:
  p height
  p width
  p name
end

But how would we call the method?

obj( height: 10, width: 20, name: "foo" )

    or

obj height: 10, width: 20, name: "foo"

Normally, such a call would look for a method called 'obj' at the top level.
The parser would need to be altered to treat 'obj' as an object *if* the
arguments are named parameters.

Interestingly, most of this implementation of named parameters exists within
the parser and need not affect the runtime greatly.  Example:

def height: width: name:

can convert to:

def height_width_name( height, width, name )

and

obj height: 10, width: 20, name: "foo"

can convert to:

obj.height_width_name( 10, 20, "foo" )

Benefits:
1.  I don't see the benefit of the Python implementation where you can
optionally define named parameters in the call. Example:

    obj.set( 10, y=20, 30 )
    obj.set( x=10, 50, z=20 )
    obj.set( y=10, z=20, x=50 )   --blah, please tell me why?

Being able to supply the parameters in any order just means that the
programmer can make the program harder to read.  I think that's bad.  I also
suspect performance overhead for this feature.

Better:

    obj( x: 10, y: 20, z: 30 )

2.  No performance hit.  It's exactly the same lookup strategy as for other
methods.

Thoughts anyone?  Like how to handle default values for arguments? ;-)

--
Justin Johnson