On Friday, 22 March 2013 at 20:04:14 UTC, foobar wrote:
> On Friday, 22 March 2013 at 10:17:02 UTC, J wrote:
>> With credit for inspiration to David Medlock in this post-- http://forum.dlang.org/thread/d9lnrr$26q3$1@digitaldaemon.com ...
>>
>> // Tongue firmly in cheek, I'd like to introduce
>> // the NAPAPISS principle: (with apologies to SFINAE and RAII)
>>
>> // NAPAPISS = NAmed Parameters Are simply Passed in a Struct, Silly.
>>
>> // Yes, indeed, maybe this is what happens after drinking too much of
>> // the fine wine products from the Napa valley... you start having
>> // wild flights of fancy of how D might surprisingly soon have
>> // named parameters....
>>
>>
>> import std.stdio;
>> import std.c.stdlib;
>>
>> void main(string[] arg) {
>>
>>    // this works today: but with the drawback that the
>>    // named params must be known at compile time...
>>
>>    // Here is a named param call,
>>    // as compact as I could get it (see struct below for actual definition).
>>
>>    auto a = myfunc!q{ z= 2; x = -123; y = 200 }(0)(); // calls opCall
>>    writeln("a=", a); // prints "a=yo", as returned from opCall
>>
>>
>>
>>    // And here's the runtime version, unfortunately you have to
>>    // pre-declare g because otherwise it won't survive the scope, and
>>    // the return value from myfunc.opCall would become inaccessible.
>>    string g;
>>    with(myfunc!()(0)) {
>>          x=rand() % 40;
>>          y=x/2;
>>          z=y/2;
>>          g = call(); // as a side effect, prints 'X 7, Y 3, Z 1'
>>     }
>>     writeln("g=", g); // prints "g=yo", as returned from opCall
>>
>>
>> /*
>>    // The bright future: this demonstrates that
>>    // it would be fairly trivial to make some kind of annotation
>>    // like @kwarg or whaterver, to indicate that a function
>>    // was using this calling convention:
>>    @kwarg string f(int a, string b) { body; }
>>
>>    // so that @kwarg function definitions are lowered to:
>>    struct f_kw {
>>      int a;
>>      string b;
>>      string f() { body; }
>>    }
>>
>>    // and calls to @kwarg functions are transformed
>>    // from this:
>>    auto r = f(a=5, b="good");
>>
>>    // into this:
>>    f_kw tmp34;
>>    tmp34.a = 5;
>>    tmp34.b = "good";
>>    auto r = tmp34.f();
>>
>>    // the benefit: named parameters can be used in a natural way,
>>    // and they need be known only at runtime.
>> */
>> }
>>
>> // how the 'works today' above examples were implemented:
>> struct myfunc(string init_string="")
>> {
>>   // named keyword or named parameters
>>   // --the call arguments and their defaults
>>   int x=0;
>>   int y=0;
>>   int z=0;
>>
>>   this(int) {}
>>   string opCall() {
>>     mixin(init_string ~ ";");
>>     writefln("X %s, Y %s, Z %s", x, y, z );
>>     return "yo";
>>   }
>>   alias opCall call;
>> }
>>
>>
>> On Friday, 22 March 2013 at 09:18:33 UTC, J wrote:
>>>
>>> The bigger point here is more profound: it is trivial to implement named parameters using structs + trivial lowerings, and this is no way conflicts with function overloading.
>>>
>>> D deserves to have named parameters to functions -- it makes for much more legible code, and obviates the need for slow builder patterns.  Readable and speedable. It's win-win.
>
> WTF? What do kwargs have to do with programming? Sounds more like a half-Klingon & half-Ferengi species to me.

kwargs = keyword arguments

It's a common naming convention in python, as exemplified in matplotlib.

On Friday, 22 March 2013 at 21:10:27 UTC, John Colvin wrote:
> On Friday, 22 March 2013 at 20:04:14 UTC, foobar wrote:

>> WTF? What do kwargs have to do with programming? Sounds more like a half-Klingon & half-Ferengi species to me.
>
> kwargs = keyword arguments
>
> It's a common naming convention in python, as exemplified in matplotlib.

That was meant more as a rhetorical question rather than a real one.
Yes, I guessed the meaning by the surrounding context but nevertheless it was a major WAT while skimming the post. Also, Who the fuck cares whats common in Python? I was reading and replying on the *D* NG, was I not?

On Friday, 22 March 2013 at 21:29:46 UTC, foobar wrote:
> On Friday, 22 March 2013 at 21:10:27 UTC, John Colvin wrote:
>> On Friday, 22 March 2013 at 20:04:14 UTC, foobar wrote:
>
>>> WTF? What do kwargs have to do with programming? Sounds more like a half-Klingon & half-Ferengi species to me.
>>
>> kwargs = keyword arguments
>>
>> It's a common naming convention in python, as exemplified in matplotlib.
>
> That was meant more as a rhetorical question rather than a real one.
> Yes, I guessed the meaning by the surrounding context but nevertheless it was a major WAT while skimming the post. Also, Who the fuck cares whats common in Python? I was reading and replying on the *D* NG, was I not?

Kwarg seems a reasonable name, consistent with a pre-existing convention. Please suggest a better alternative if you have one. I must admit I'm bemused by your level of aggression over what appears to be a trivial matter.

>> auto s=callNamed!(fun,`x,y`)(10,20);

Thanks, but this is a non-solution.

The name must be next to the value ( x=10, y=20), so they it will scale from 2 to 7 to 17 arguments and maintain readability.

On Saturday, 23 March 2013 at 05:43:22 UTC, J wrote:
>>> auto s=callNamed!(fun,`x,y`)(10,20);
>
> Thanks, but this is a non-solution.
>
> The name must be next to the value ( x=10, y=20), so they it will scale from 2 to 7 to 17 arguments and maintain readability.

For a use case, compare this call

reflectAndTranslate(2, 4, 5, 6, 1, 2, false, true, 15, false, true, false);


Quick, without looking at the docs, what does the false after 15 do?

It's very hard to tell. Compare that to:


reflectAndTranslate(x=2, y=4, z=5,  offset=6, alpha=1, beta=2, invert=false, twist=true, colorBrush=15,  stideReduce=false, bindMatrix=true, slow=false);


It's self documenting.

On Friday, 22 March 2013 at 21:41:46 UTC, John Colvin wrote:
> On Friday, 22 March 2013 at 21:29:46 UTC, foobar wrote:
>> On Friday, 22 March 2013 at 21:10:27 UTC, John Colvin wrote:
>>> On Friday, 22 March 2013 at 20:04:14 UTC, foobar wrote:
>>
>>>> WTF? What do kwargs have to do with programming? Sounds more like a half-Klingon & half-Ferengi species to me.
>>>
>>> kwargs = keyword arguments
>>>
>>> It's a common naming convention in python, as exemplified in matplotlib.
>>
>> That was meant more as a rhetorical question rather than a real one.
>> Yes, I guessed the meaning by the surrounding context but nevertheless it was a major WAT while skimming the post. Also, Who the fuck cares whats common in Python? I was reading and replying on the *D* NG, was I not?
>
> Kwarg seems a reasonable name, consistent with a pre-existing convention. Please suggest a better alternative if you have one. I must admit I'm bemused by your level of aggression over what appears to be a trivial matter.

Your read it wrong. Not aggression but rather annoyment.
Also, code readability is NOT a trivial matter and people who think that it is should have their keyboard chopped off.

IMHO, I think the entire feature is a code smell and glad D does not support it. Code that needs named parameters to be more readable is poorly designed code in the first place.

On Saturday, 23 March 2013 at 08:20:19 UTC, J wrote:
> On Saturday, 23 March 2013 at 05:43:22 UTC, J wrote:
>>>> auto s=callNamed!(fun,`x,y`)(10,20);
>>
>> Thanks, but this is a non-solution.
>>
>> The name must be next to the value ( x=10, y=20), so they it will scale from 2 to 7 to 17 arguments and maintain readability.
>
> For a use case, compare this call
>
> reflectAndTranslate(2, 4, 5, 6, 1, 2, false, true, 15, false, true, false);
>
>
> Quick, without looking at the docs, what does the false after 15 do?
>
> It's very hard to tell. Compare that to:
>
>
> reflectAndTranslate(x=2, y=4, z=5,  offset=6, alpha=1, beta=2, invert=false, twist=true, colorBrush=15,  stideReduce=false, bindMatrix=true, slow=false);
>
>
> It's self documenting.

I'd argue that with or without named parameter, that code is ugly as hell.

First, boolean can be replaced by enums for great benefice. Secondly, the usage of struct would also improve things quite a lot (x, y, z) is a point or a vector or something.

At the end, it is about giving semantic to your code.

BTW, monadic style named parameters have been proposed earlier, and I have to say this is really nice.

foobar:

> Code that needs named parameters to be more readable is poorly designed code in the first place.

Have you used a language where the usage of named arguments is idiomatic, like Python, Scala or Ada? They are sometimes useful even for well designed code, like functions with two arguments.

Bye,
bearophile

On 2013-03-22 21:02, Dmitry Olshansky wrote:

> Can opDispatch & chaining  be leveraged to get the effect of:
> named!(fun).x(10).y(20).call();

Here you go:

http://pastebin.com/ALaXLgt3

Use that together with "callNamed" from timotheecour.

-- 
/Jacob Carlborg

On Saturday, 23 March 2013 at 15:00:13 UTC, bearophile wrote:
> foobar:
>
>> Code that needs named parameters to be more readable is poorly designed code in the first place.
>
> Have you used a language where the usage of named arguments is idiomatic, like Python, Scala or Ada? They are sometimes useful even for well designed code, like functions with two arguments.
>
> Bye,
> bearophile

A simple example is matplotlib.pyplot.plot

There are so many possible flags and parameters that can be passed in order to get the exact behaviour you want, but commonly you'll only want a few set for each call. You don't want to have to set all the other preceding parameters, you just want to go e.g. plot(data, linewidth=5)