From: Trans <transfire@...>
Date: 2005-10-21T23:12:00+09:00
Subject: Re: A comparison by example of keyword argument styles


Berger, Daniel wrote:

> The separation between implementation and behavior you make here is lost
> the moment you commit to supporting a keyword argument for any given
> method, regardless of the fact that it was an explicit, conscious
> choice.  Once chosen, you're still beholden to that keyword name forever
> unless you want to break backwards compatability.  I think the perceived
> freedom is an illusion.
>
> There seems to be this fear of using an argument name, and then later
> changing your mind about what the argument name should be called.  To
> that I reply that, even with the explicit syntax, this issue does not go
> away.  I would also say that all the implicit syntax does is force you
> to think more up front about your API and naming conventions.  With
> Sydney, at least you can resort to positional parameters in the unlikely
> event that the argument name did change, something you can't do with
> Matz's current proposal afaik.

I must say, I was leaning with David, but these are good counter
arguments.

Perhaps we should just sing a song and "Let's Call The Whole Thing
Off". If keywords integrate the interface too tightly with the code,
then why tie them to the interface? Also, I imagine there many be many
more keyword arguments then ordered args, this will make for some very
LONG constructors:

  def stadium( height:, seating_capacity:, location:, color:, sports:,
concessions:, extra_features:, indoor:, yadayadayada: )

So maybe just treat named parameters like blocks. You can have em or
not. But you don't need to define them in the interface. Currently I do
a lot of

  def( *args )
    keys = args.last.is_a?(Hash) ? args.pop : {}
    a,b,c = *args

If I could just do

  def( a, b, c, **keys )
    ...

I'd be happy enough.

T.

P.S. But I don't much care for double character '**'. Single character
would be better. Perhaps '#' or '%'.