From: "David A. Black" <dblack@...>
Date: 2005-10-21T22:57:16+09:00
Subject: Re: A comparison by example of keyword argument styles

Hi --

On Fri, 21 Oct 2005, Berger, Daniel wrote:

>> -----Original Message-----
>
>> Amen. As I keep saying, it's a matter of interface. If you
>> allow implicit keyword arguments, you're suddenly mixing
>> interface and implementation, and that is *wrong* (in the
>> sense that it is difficult to maintain, and it breaks the
>> promise of encapsulation). However, if you explicitly decide
>> that some argument is a keyword argument, you have
>> *consciously* made it part of the interface (I'd rather say
>> part of the very *name* of the method), so you can still
>> maintain the separation between interface and implementation
>> to the level you want as a developer.
>
> 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.

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.

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

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


David

-- 
David A. Black
dblack@wobblini.net