Selon "Berger, Daniel" <Daniel.Berger / qwest.com>:

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

I happen to think that the fact that it was an explicit, conscious choice does
make a difference.

  Once chosen, you're still beholden to that keyword name forever
> unless you want to break backwards compatability.

Yes, but you chose for it. In your implementation, the language chooses already
for the developer. Sorry, but although a language always makes some choices for
the developer, there are some that are more justified than others. This is one
in my opinion that is not justified.

  I think the perceived
> freedom is an illusion.
>

That's your opinion. In my opinion it's very real.

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

No, but at least you chose for the situation.

  I would also say that all the implicit syntax does is force you
> to think more up front about your API and naming conventions.

Too much in my opinion. Argument names shouldn't be part of the API unless one
explicitly chooses it that way. Also, having to think upfront about all the
details of your implementation, just to get a stable API, is not how software
is built. That's the main thing I don't like about your proposal: changing a
method's implementation under Sydney's implementation is much more likely to
change the API of the method than under Matz's proposal, *because you never
know who will call your arguments positionally and who will call them by
keyword.* Despite what you may think, the loss of freedom for the developer is
very real, and the coupling between interface and implementation far too strong
to be comfortable.

Sorry, but when I have positional arguments, I only want to have to worry about
their position for the API, and when I have keyword arguments, I only want to
have to worry about their names for the API. In your proposal I have to worry
about both, for all arguments. You seem to think that your proposal adds the
advantages of both styles. In my opinion it only adds together their drawbacks.
The advantages of keyword arguments disappear when there's a chance that someone
will call them positionally, and the advantages of positional arguments
disappear when there's a chance that someone will use them with keywords.

  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.

And then the programmer changes the order of the arguments because it fits
better the meaning of the definition and you lose anyway. Sorry, but I don't
think that's a gain. If the developer changes the API, change your program.
Such kind of stop-gap measure brings nothing but trouble. I think it only
encourages sloppiness, both for the developer and the user.
--
Christophe Grandsire.

http://rainbow.conlang.free.fr

It takes a straight mind to create a twisted conlang.