On 12/29/2011 02:02 AM, so wrote:
> 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)

Documentation can be improved over time.
It cannot be argued that the widening of the set of exposed names is a positive aspect of named arguments.

Timon Gehr:

> 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

I don't agree. Names are among the most important things in a human mind, if you find the right names, API usability improves. Thinking about the best names is time well spent, especially for library functions used by a lot of all kind of people for a lot of time.

Bye,
bearophile

On 12/29/2011 03:38 AM, bearophile wrote:
> Timon Gehr:
>
>> 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
>
> I don't agree. Names are among the most important things in a human mind, if you find the right names, API usability improves. Thinking about the best names is time well spent, especially for library functions used by a lot of all kind of people for a lot of time.
>
> Bye,
> bearophile

My point is, without named arguments you can improve the names at any time. With named arguments, you are stuck and have to get it right upfront.

Timon Gehr:

> My point is, without named arguments you can improve the names at any time. With named arguments, you are stuck and have to get it right upfront.

I think library code doesn't change argument names often, and when this happens I have suggested a way to deprecate argument names. Somehow Scala and Ada programmers survive to that :-)

Bye,
bearophile

On 12/29/11 3:46 AM, Timon Gehr wrote:
> My point is, without named arguments you can improve the names at any
> time. With named arguments, you are stuck and have to get it right upfront.

My point is, without positional arguments you can improve the ordering at any time. With positional arguments, you are stuck and have to get it right upfront.

David

On 29.12.2011 02:02, so wrote:
> 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)

sin(real x);
sin(real theta);

The argument name is *completely* irrelevant. That shouldn't be part of the interface.

I have a really really bad taste in my mouth from named arguments in COM.

On 29.12.2011 04:48, David Nadlinger wrote:
> On 12/29/11 3:46 AM, Timon Gehr wrote:
>> My point is, without named arguments you can improve the names at any
>> time. With named arguments, you are stuck and have to get it right
>> upfront.
>
> My point is, without positional arguments you can improve the ordering
> at any time. With positional arguments, you are stuck and have to get it
> right upfront.
>
> David

That's rubbish! Unless you plan to disallow positional arguments...

On 28.12.2011 13:14, Timon Gehr wrote:
> On 12/28/2011 10:53 AM, Peter Alexander wrote:
>> On 27/12/11 8:40 PM, Andrei Alexandrescu wrote:
>>> On 12/27/11 2:38 PM, Walter Bright wrote:
>>>> On 12/27/2011 12:28 PM, Andrei Alexandrescu wrote:
>>>>> One good realization to make is how less efficient that makes you. You
>>>>> got used
>>>>> to that overhead so plentily, you consider it now par for the course.
>>>>
>>>> What takes time is running the unittests, not compiling dmd.
>>>
>>> Then _that_ is what you consider par for the course! :o)
>>>
>>> Andrei
>>
>> Has anyone looked into what causes the unittests to take so long? I find
>> it hard to believe that they need to take as long as they do.
>
> They have to be run for many different combinations of compiler flags iirc.
AFAIK there has never been a failure which wasn't with one of:
(no flags)
-O -release -inline
-g -O -release -inline

But why do the Phobos unit tests take so long? They used to take a matter of seconds, now they take forever.

On D1, they still take only about 10 seconds. On D2 they are now longer than the compiler tests with the minimal flag options.

Naming is much less error-prone, then positioning, because change in
position is much less obvious (especially for parameters of the same
type).
When you write a class or a function you also need to come up with a
name, but you don't think of it as being forced to think ahead.
You'll always need to think ahead no matter what you do. A
sufficiently easy named parameter mechanism can easily allow you to
deprecate names if necessary.
Moreover, disallowing positional parameters is absolutely not
necessary, because it would lead to ugly code:

sin(5)
sin(x : 5)

I think the best idea would be to allow both named and positional, but disallow mixing them. That is, you can either pass all your parameters by name or by position.

int[2] makeAPoint(int x, int y) { return [x, y]; }

unittest
{
    auto a0 = makeAPoint(5, 7); // valid
    auto a1 = makeAPoint(x : 5, y : 7); // valid
    auto a2 = makeAPoint(5, y : 7); // invalid
    auto a2 = makeAPoint(x : 5, 7); // invalid
}

I really don't see any benefits in allowing mixed calls. in those cases you might as well encapsulate the parameters in a structure.

On Thu, Dec 29, 2011 at 12:08 PM, Don <nospam@nospam.com> wrote:
> On 29.12.2011 04:48, David Nadlinger wrote:
>>
>> On 12/29/11 3:46 AM, Timon Gehr wrote:
>>>
>>> My point is, without named arguments you can improve the names at any time. With named arguments, you are stuck and have to get it right upfront.
>>
>>
>> My point is, without positional arguments you can improve the ordering at any time. With positional arguments, you are stuck and have to get it right upfront.
>>
>> David
>
>
> That's rubbish! Unless you plan to disallow positional arguments...



-- 
Bye,
Gor Gyolchanyan.

On Thu, 29 Dec 2011 19:07:17 +1100, Don <nospam@nospam.com> wrote:


> sin(real x);
> sin(real theta);
>
> The argument name is *completely* irrelevant. That shouldn't be part of the interface.
>
> I have a really really bad taste in my mouth from named arguments in COM.

Were you forced to use named parameters or was it optional?

-- 
Derek Parnell
Melbourne, Australia