From: gabriele renzi <surrender_it@...>
Date: 2005-10-23T20:42:02+09:00
Subject: Re: A comparison by example of keyword argument styles

David A. Black ha scritto:

>> 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.
> 
> 
> But that's the point: keyword arguments represent a decision to name
> your arguments.  It's just like a hash.  If I say that my method takes
> a hash:
> 
>   :first_name => ..., :last_name => ...
> 
> then of course I've committed to those keys, and can't change them
> whenever I feel like it.

My 2c, some side view to add to this multifaceted debate:
I think you're supposing people will use your keyword arguments, which 
is in many cases unrealistic.
It does not matter what the names are if an user would use them only 
when they make sense (i.e. I won't call p(obj: foo) )

OTOH whenever you expect people to use your arguments by name (i.e. 
:rails =>stuff) you would commit anyway to keyword arguments even with 
the dual-scheme. Do you think otherwise?

> I just don't see why it has to be a winner-take-all situation, when
> it's perfectly possible to have both keywords arguments and
> "uncoupled" positional arguments.

because it is much simpler, and it avoid the need for an author to 
choose beetween two different schemes.


>> 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.
> 
> 
> It's not a fear: it's a right :-)  Having local variable names always
> be part of the API just doesn't make sense to me at all.

I think they are already part of an api, since they are documentation.
They may not be strictly enforced but you're still not expected to 
change them since
  Time.new(duration)
is meaningful to people reading the api.

>> 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.
> 
> 
> But that means the caller has to keep track of whether or not the
> maintainer of the code has change variable names.  I don't want to be
> on either end of that.  It could be a refactoring and/or maintenance
> nightmare.

I also heard you can't have a reliable application written in dynamic 
languages, since they can be a refactoring and/or maintenance nightmare, 
the fact is that this is wrong ;)

Python people have been using a merged-named-and-positional scheme for 
some years and it never shown itself as a problem (actually, I think it 
helps refactoring tools based on heuristics).

There could be other problems (i.e. the c api) with this scheme, but I 
think this kind of fear is unmotivated