Re: Named paramters again

----- Original Message -----
From: "Justin Johnson" <[e-mail]>


>
> 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.

AFAIC, the *point* of allowing (*not* enforcing) named parameters is so that
the programmer can alter the parameter order.  That way, if a method has
several parameters, you don't have to remember the order.  This is really
only suited to those situations where a class or method is data-heavy.  In
these situations, there is generally nothing special about parameter order.

I can't think of any method of the built-in classes that would benefit from
named parameters.

Nobody should be forced to use named parameters, so who cares about 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.

A nice experiment, perhaps, but methods have names for a reason: to indicate
what they do.

> 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?

Why not?  If x, y and z are simply properties of the object that need to be
set, the programmer's intention couldn't be more explicit than the third
line above.  Apart from their alphabetical order, which does not generalise,
there is nothing suggesting anything special about the order they are
specified in.

> 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.

Imagine the following method:

  def calculate_maintenance(bulls, sheep, chickens)

Which is clearer:
  calculate_maintenance(400, 251, 49)
or
  calculate_maintenance(chickens:49, bulls:400, sheep:251)
?

There is no significance to the order of the parameters, so its easy to get
the arguments around the wrong way.

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

What's the difference?  No method name (surely *that* makes the program
harder to read), and using : instead of =.  Big deal.

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

Performance shmerformance.  Clear, maintainable solutions are more expensive
than faster equipment.  Ruby is not likely to be a performance gun anytime
soon, and a named parameters strategy won't change that much either way.

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

My thoughts on named parameters:

1. They are a useful convenience in a limited set of cases, not a magic
bullet or killer gimmick for a language.

2. If used widely, they will make code difficult to read.

3. They should not be mandatory.  (Shouldn't need stating, should it?)

4. (1) & (2) -> One can only provide named arguments if the method was
defined to receive them.  (This could be bothersome to specify and may not
meet with agreement.)

5. Even for methods that have named parameters, anonymous arguments are
allowed.  Mixing anonymous and named parameters in a method call is
prohibited.

6. When someone writes a method that takes named parameters, they should
stop and think whether they can make it unnecessary (by reducing the number
of parameters, for instance).

Just my 14c.

> --
> Justin Johnson
>


Gavin