On Wednesday, 28 December 2011 at 22:57:29 UTC, bearophile wrote:
> (while I have not written a significant amount of functional-style code in Javascript)

It looks fine if you use named functions or a little whitespace
around the literals (same as D!).

On Wednesday, 28 December 2011 at 20:58:33 UTC, Jonathan M Davis wrote:
> Since they affect the API, they _do_ hurt

In my web.d, I support named and positional parameters for
remote calls.

I almost always use the positional parameters exactly because
they are not affected by name changes in the server app.

It's just so much easier to handle changes when the names
don't matter.


Though it might not be so bad in D since static checks
can help. I remember one time this was discussed, it was
suggested to allow the name if and only if the position
is correct too.

void foo(int a, int b);
foo(a: 1, b: 0); // ok
foo(A: 1, b: 0); // wrong name
foo(b: 1, a: 0); // wrong names because position is swapped


Though imo if you want that, you could always just use a comment.

Timon Gehr:

> Having parameter names contribute to the interface means that all developers need to spend time thinking about the best possible names for their function parameters.

And this is a good thing :-) It helps you understand the function purpose better.

Bye,
bearophile

On Thu, 29 Dec 2011 01:48:57 +0200, Timon Gehr <timon.gehr@gmx.ch> wrote:

> The moment NP by default is introduced is the moment all parameter names in all libraries are set in stone.

This is completely false. NP affects only those that "want" to use it, no one else. Again, no one.
It is just like inline asm.

> Those names were mere implementation details prior to that point in time.
> Having parameter names contribute to the interface means that all developers need to spend time thinking about the best possible names for their function parameters.
>
>> Then, what makes you so sure he won't do this?
>
> What makes you so sure that if he does, he actually remembers to change the functionality too?

You are not making any sense here i am sorry.
Read the examples.

He doesn't need to remember, compiler does that for him but only for him :)

On Thu, 29 Dec 2011 01:58:46 +0200, so <so@so.so> wrote:

> He doesn't need to remember, compiler does that for him but only for him :)

As it turns out compiler don't give a damn about him either.

On 12/29/2011 12:58 AM, so wrote:
> On Thu, 29 Dec 2011 01:48:57 +0200, Timon Gehr <timon.gehr@gmx.ch> wrote:
>
>> The moment NP by default is introduced is the moment all parameter
>> names in all libraries are set in stone.
>
> This is completely false. NP affects only those that "want" to use it,
> no one else. Again, no one.
> It is just like inline asm.
>

No, it is not. If all parameters are named parameters, then the library writers have to be aware of the fact that some users might use named arguments. Again, every library writer is affected.

>> Those names were mere implementation details prior to that point in time.
>> Having parameter names contribute to the interface means that all
>> developers need to spend time thinking about the best possible names
>> for their function parameters.
>>
>>> Then, what makes you so sure he won't do this?
>>
>> What makes you so sure that if he does, he actually remembers to
>> change the functionality too?
>
> You are not making any sense here i am sorry.

That was the point. I was continuing the reasoning in your previous post.

On Thu, 29 Dec 2011 02:14:18 +0200, Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 12/29/2011 12:58 AM, so wrote:
>> On Thu, 29 Dec 2011 01:48:57 +0200, Timon Gehr <timon.gehr@gmx.ch> wrote:
>>
>>> The moment NP by default is introduced is the moment all parameter
>>> names in all libraries are set in stone.
>>
>> This is completely false. NP affects only those that "want" to use it,
>> no one else. Again, no one.
>> It is just like inline asm.
>>
>
> No, it is not. If all parameters are named parameters, then the library writers have to be aware of the fact that some users might use named arguments. Again, every library writer is affected.

Show me any library code from any language where library writer is not already "aware" their argument names define their function.
They even document it that way.

/// a does this, b does that
void fun(int a, int b)

On Thu, 29 Dec 2011 10:48:57 +1100, Timon Gehr <timon.gehr@gmx.ch> wrote:

> Having parameter names contribute to the interface means that all developers need to spend time thinking about the best possible names for their function parameters.

And that's a bad thing, right?

Named parameters do have the issue that once released, it is can be costly to change the names. It therefore is important that library developers take enough time to consider parameter names, much in the same manner as they are currently consider existing exposed names.

To assist those developers, a name deprecation facility could be introduced to alert users of pending removal of old names. This would of course only be of interest to those developers who choose to use named parameters in their code.

There is a similar issue with positional parameters; once released, the library developer would be unwise to alter the order of parameters. But somehow, we have managed to educate ourselves so as to (mostly) avoid this problem.


In general, I'd support optional named parameters and would encourage their usage in those situations where it makes source code more understandable to other readers.

-- 
Derek Parnell
Melbourne, Australia

On Thu, 29 Dec 2011 12:02:28 +1100, so <so@so.so> wrote:

> Show me any library code from any language where library writer is not already "aware" their argument names define their function.

Supporting example:

   int find( T needle, T[] haystack)



As a side effect, it might even help prevent the unnecessary use of one-character parameter names, LOL.

-- 
Derek Parnell
Melbourne, Australia

On 12/29/2011 02:04 AM, Derek wrote:
> On Thu, 29 Dec 2011 10:48:57 +1100, Timon Gehr <timon.gehr@gmx.ch> wrote:
>
>> Having parameter names contribute to the interface means that all
>> developers need to spend time thinking about the best possible names
>> for their function parameters.
>
> And that's a bad thing, right?

If the time was better spent at creating functionality, yes.

http://www.digitalmars.com/d/archives/digitalmars/D/Rename_std.string.toStringz_138740.html

http://www.digitalmars.com/d/archives/digitalmars/D/Fixing_enum_names_in_Phobos_141507.html

http://www.digitalmars.com/d/archives/digitalmars/D/std.getopt_suggestion_145648.html#N145648

http://www.digitalmars.com/d/archives/digitalmars/D/renamepalooza_time_127446.html

...
etc.


>
> Named parameters do have the issue that once released, it is can be
> costly to change the names. It therefore is important that library
> developers take enough time to consider parameter names, much in the
> same manner as they are currently consider existing exposed names.
>
> To assist those developers, a name deprecation facility could be
> introduced to alert users of pending removal of old names. This would of
> course only be of interest to those developers who choose to use named
> parameters in their code.
>
> There is a similar issue with positional parameters; once released, the
> library developer would be unwise to alter the order of parameters. But
> somehow, we have managed to educate ourselves so as to (mostly) avoid
> this problem.
>
>
> In general, I'd support optional named parameters and would encourage
> their usage in those situations where it makes source code more
> understandable to other readers.
>

I am indifferent whether or not to add them.