Christophe Grandsire wrote:

<snip>

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

But it *is* you who chooses it when you choose the parameter name.  I don't 
feel the loss of control you seem to feel.  I guess we're getting into 
programmer psychology here. ;)

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

*All* of the details of the implementation? No, just the parameter names. 
That's a far cry from "all" IMO.

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

My reply to this would be that major refactorings usually break backwards 
compatability anyway, and the positional versus keyword argument becomes moot. 
  That, or you have to jump through extra hoops to maintain it.

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

We'll have to agree to disagree. :)

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

You lose with either implementation if positional parameters change (or even 
current Ruby).

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

Encourages sloppiness?  I think it will have the opposite effect.

I should also point out that Sydney *could* make keyword arguments optional by 
resorting to a more explicit behavior style API, e.g.

class Foo
    behavior KeywordBehavior
    def initialize(x, y, z)
       ...
    end
end

This would give all methods of class Foo implicit keyword parameters.  But, 
perhaps we could make it even more granular (though I'm not certain without 
asking Evan).  I'm just making stuff as I go here, but perhaps this:

class Foo
    behavior KeywordBehavior
    def bar(x, y, z)
       ...
    end
    def baz(a, b = 4)
       ...
    end

    # Add keyword support for parameter 'z' in method 'bar'
    KeywordBehavior.keyword_argument(:bar => "z")
end

Ok, it gets pretty verbose when you get that granular, but I thought I would 
toss it out there.

Regards,

Dan