From: Christophe Grandsire Date: 2005-10-21T23:17:16+09:00 Subject: Re: A comparison by example of keyword argument styles Selon "Berger, Daniel" : > > 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.