On 03/01/2011 08:49 AM, Jacob Carlborg wrote:
> On 2011-02-28 22:38, Don wrote:
>> But I still don't see the need for this feature. Aren't people using
>> IDEs where the function signature (with parameter names) pops up when
>> you're entering the function, and when you move the mouse over the
>> function call?
>> And if you really want to see them all the time, why not build that
>> feature into the IDE?
>> ("hit ctrl-f9 to show all parameter names, hit it again to hide them").
>
> That's very true. I'm used to that with Descent. On the other hand, I don't
> know how many editors that support this that also supports D.

And how does this feature help the reader and decode:
	f(1,"a",true);
?

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On 03/01/2011 01:50 AM, Stewart Gordon wrote:
> Trouble is it would create fragility, as parameter names would become a new
> thing that can't be changed once decided without breaking existing code.  So it
> would be important to get them right from the beginning, and there'll be a time
> when the feature has just been introduced during which library programmers are
> in the process of changing parameter names to something meaningful.  But one
> way around that would be to support parameter aliases, which would also confer
> a few more benefits.

That is a real concern, indeed, and the only rational point until now possibly interpretable against named parameters: once a lib is adopted, the feature freezes param names --just like type names, funcs names, member names, constant names, alias names and so on and so forth.
On the other hand, this will hopefully prevent lib authors using meaningless/helpless names from the start on ;-) It may even help & promote de facto or discussed conventions on param names (ideally, one would be able to guess half of them from the /meaning/ of parameters)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On Tue, 01 Mar 2011 12:20:22 +0100, spir wrote:

> On 02/28/2011 11:13 PM, Steven Schveighoffer wrote:
>>> But I still don't see the need for this feature. Aren't people using IDEs where the function signature (with parameter names) pops up when you're entering the function, and when you move the mouse over the function call?
> 
> You are wrong Don, this is not an argument. The feature is *not* for writing code, but for reading it (first your own code). Obviously, if you can write parameter names, this means you know them somehow, lol! The names provide highly valuable info at /reading/ time.
> 
>> Dunno, vim doesn't do that for me currently.  Also, if reviewing code on github, there is no ide.
> 
> Geany does it, but only for currently open files. Meaning, to have it work when programming in D, I should have the whole stdlib open in geany tabs... Anyway, as said above, this feature is 'orthogonal' to the question discussed in this thread.
> 
> I'm fed up with people opposing to features very relevant for code
> clarity, which they are not forced to use, and can hardly bother when
> reading code themselves. Is the second statement below really that hard
> to read?
> 	p = new Point([1,2,3], [3,2,1]);
> 	p = new Point(color:[1,2,3], pos:[3,2,1]);

Are the following really that hard to read?

  p = new Point(/* color */ [1,2,3], /* pos */ [3,2,1]);

  p = new Point(
        [1, 2, 3],    // color
        [3, 2, 1],    // pos
        );

-Lars

On Tue, 01 Mar 2011 04:10:12 -0500, Don <nospam@nospam.com> wrote:

> Steven Schveighoffer wrote:
>> On Mon, 28 Feb 2011 16:38:34 -0500, Don <nospam@nospam.com> wrote:
>>
>>> spir wrote:
>>>>  Just don't use them!
>>>
>>> You don't have that option. At least, if you're a library developer, you don't. (I'm a bit sick of people saying "you don't have to use it if you don't want to" in language design. If it is in the language, you don't have a choice. You will encounter it).
>>  encounter *reading* it or encounter *using it*?  You shouldn't ever have to use named parameters if you don't want to.  Just like you can specify all defaulted parameters, or specify all template args when calling templated functions.
>>  I could live without named parameters (obviously!), but I certainly think reading a call with named parameters can be much easier with the parameter names than without, and I don't think you could ever say the opposite (that name-less parameters would be clearer).
>
> For sure they can be clearer with nameless parameters!
>
> printf(formatstr: "Hello World!\n");

This is not less clear than printf("Hello World!\n");   It's as clear.  More verbose, yes, but clear.

Just like foo!int(1) is as clear as, but more verbose than, foo(1).

>> In essense, the parameter names are ALREADY an essential part of the API.  If we didn't name the parameters (entirely possible with .di files!), how shitty would programming be?
>
> The names are for humans to read. They are documentation. That's a big difference.

And they continue to be documentation, I'm documenting what my argument names are at the call site so I don't have to go back to the function definition to determine what each parameter is via position.

Regarding your objection in another post, I see your point that you don't want to break existing code by changing a parameter name.  A way to look at this is, you must choose good parameter names on the first try.  Another way to look at it is, I'm documenting my function call -- I want to be notified by the compiler when the parameter names changed because I want to reassure myself that the call is still valid.  My point is, the function author should choose good names, but if he must make a change, then fear of breaking calls should not dissuade him.  We routinely change the names of functions or deprecate them, this is taken in stride by the users of the library, I don't see how changing parameter names is any different.

-Steve

On 03/01/2011 05:52 AM, Bekenn wrote:
> On 2/28/2011 8:43 PM, Andrei Alexandrescu wrote:
>> Don't know about others, but I think this is exactly the point where my
>> "meh" detector goes off.
>
> It *might* be worthwhile if it does indeed address Jonathan's concern about
> library writers not being able to change parameter names. I'm not sold that
> that's really such a big deal; I expect that parameter name aliases would be so
> rarely used as to disappear into obscurity. But I could be wrong.

Should we also have some mechanism to help lib writers and change type names, func names, member names...?

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On 03/01/2011 02:48 AM, Andrei Alexandrescu wrote:
> On 2/28/11 6:03 PM, Jonathan M Davis wrote:
>> The more I think about this, the more I'm against the idea of named arguments.
>
> I think you have been blessed to work with only small, clean APIs. Certain
> domains definitely promote large argument lists. Though the designs could
> certainly be refactored to e.g. group parameters into separate objects, it's
> overkill to do that. I'm afraid sheer experience is showing that your
> counterarguments are not based.

It seems to me the core point is whether what params mean, and their order, is obvious. Rather than their sheer number. Reading code using names for params is a huge help in understanding it, and also in learning the APIs. Meaning what one can do, why it is useful, and how to proceed concretely.
I would be for all tutorial-like code (esp in "official" ref doc), examples, and even unittests more or less intended as code samples, to use named params everywhere.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On 03/01/2011 02:36 AM, Andrei Alexandrescu wrote:
> On 2/28/11 12:38 PM, Bekenn wrote:
>> On 2/28/11 5:48 AM, Andrei Alexandrescu wrote:
>>> One more thing, order of evaluation should still be left-to-right, not
>>> in order of arguments. This means the feature cannot be a syntactic
>>> rewrite (not a big issue, but definitely something to keep in mind).
>>>
>>>
>>> Andrei
>>
>> I was thinking that order of evaluation should remain lexically
>> left-to-right at the point of call (that is, in the order the arguments
>> are specified, with any remaining default parameters coming after); is
>> there a reason that would be bad or wouldn't work?
>
> I meant the same as you.

I agree with this. Keeping order makes things simpler, probably helps implementation of the feature (I guess), and removes nearly nothing imo. Named params are about helping reading code.

On the other hand, I would like it still be possible to write:
	void f (x=0, y=0) {...}
	...
	f(y=1);

This is unorderd strictly speaking...
(Sorry for my possibly wrong English)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On Mon, 28 Feb 2011 19:50:44 -0500, Stewart Gordon <smjg_1998@yahoo.com> wrote:

> On 28/02/2011 07:03, Bekenn wrote:
>>     HRESULT hr = m_Device.Present(pSourceRect: null, pDestRect: null, hDestWindowOverride: null, pDirtyRegion: null);
>
> One advantage is that it would encourage self-documenting code, partly because the meaning is clearer at the caller side, and partly because library programmers would be encouraged more to make parameter names meaningful.
>
> It also means that you don't have to remember which order the parameters of a function go in.  Though this is only useful if you can remember what the parameters are called.  For example, string search functions vary - needle/haystack, str/substr, search/seek, for/in.   (OK, so some of these I've thought up on the spot, and for/in wouldn't work (nice as it may be) as they're keywords, but you get the idea.)
>
> Trouble is it would create fragility, as parameter names would become a new thing that can't be changed once decided without breaking existing code.  So it would be important to get them right from the beginning, and there'll be a time when the feature has just been introduced during which library programmers are in the process of changing parameter names to something meaningful.  But one way around that would be to support parameter aliases, which would also confer a few more benefits.

This is probably the worse concern, because right now, phobos has been created without the intention that parameter names will be used at the call site.  Despite all the concern, I believe phobos has been naming parameters just fine.  If there are any poorly named parameters, they either a) aren't worth worrying about or b) should be renamed anyways (even if named parameter calling is not introduced).

I think the alias idea is too much...

-Steve

On 03/01/2011 12:48 PM, Lars T. Kyllingstad wrote:
> On Tue, 01 Mar 2011 12:20:22 +0100, spir wrote:
>
>> On 02/28/2011 11:13 PM, Steven Schveighoffer wrote:
>>>> But I still don't see the need for this feature. Aren't people using
>>>> IDEs where the function signature (with parameter names) pops up when
>>>> you're entering the function, and when you move the mouse over the
>>>> function call?
>>
>> You are wrong Don, this is not an argument. The feature is *not* for
>> writing code, but for reading it (first your own code). Obviously, if
>> you can write parameter names, this means you know them somehow, lol!
>> The names provide highly valuable info at /reading/ time.
>>
>>> Dunno, vim doesn't do that for me currently.  Also, if reviewing code
>>> on github, there is no ide.
>>
>> Geany does it, but only for currently open files. Meaning, to have it
>> work when programming in D, I should have the whole stdlib open in geany
>> tabs... Anyway, as said above, this feature is 'orthogonal' to the
>> question discussed in this thread.
>>
>> I'm fed up with people opposing to features very relevant for code
>> clarity, which they are not forced to use, and can hardly bother when
>> reading code themselves. Is the second statement below really that hard
>> to read?
>> 	p = new Point([1,2,3], [3,2,1]);
>> 	p = new Point(color:[1,2,3], pos:[3,2,1]);
>
> Are the following really that hard to read?
>
>    p = new Point(/* color */ [1,2,3], /* pos */ [3,2,1]);
>
>    p = new Point(
>          [1, 2, 3],    // color
>          [3, 2, 1],    // pos
>          );

Just like the unittest feature is very simple and brings no new functionality (you can very easily write unittests w/o the feature), but having them an official feature makes it nicer, obvious, and used everywhere.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

"Lars T. Kyllingstad" <public@kyllingen.NOSPAMnet> wrote in message news:ikimed$2vba$5@digitalmars.com...
> On Tue, 01 Mar 2011 12:20:22 +0100, spir wrote:
>
>> On 02/28/2011 11:13 PM, Steven Schveighoffer wrote:
>>>> But I still don't see the need for this feature. Aren't people using IDEs where the function signature (with parameter names) pops up when you're entering the function, and when you move the mouse over the function call?
>>
>> You are wrong Don, this is not an argument. The feature is *not* for writing code, but for reading it (first your own code). Obviously, if you can write parameter names, this means you know them somehow, lol! The names provide highly valuable info at /reading/ time.
>>
>>> Dunno, vim doesn't do that for me currently.  Also, if reviewing code on github, there is no ide.
>>
>> Geany does it, but only for currently open files. Meaning, to have it work when programming in D, I should have the whole stdlib open in geany tabs... Anyway, as said above, this feature is 'orthogonal' to the question discussed in this thread.
>>
>> I'm fed up with people opposing to features very relevant for code
>> clarity, which they are not forced to use, and can hardly bother when
>> reading code themselves. Is the second statement below really that hard
>> to read?
>> p = new Point([1,2,3], [3,2,1]);
>> p = new Point(color:[1,2,3], pos:[3,2,1]);
>
> Are the following really that hard to read?
>
>  p = new Point(/* color */ [1,2,3], /* pos */ [3,2,1]);
>
>  p = new Point(
>        [1, 2, 3],    // color
>        [3, 2, 1],    // pos
>        );
>
> -Lars

class Point {
    this(int[3] pos, int[3] color) {...}
}

p = new Point(/* color */ [1,2,3], /* pos */ [3,2,1]);

Big Fail.