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.

"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.2069.1298937813.4748.digitalmars-d@puremagic.com...
>
> And that's a _big_ problem. For instance, how many parameter names in
> Phobos
> were chosen with the idea that a caller would use them? _None_.

If Phobos parameter names are that bad, then Phobos has both a code-quality problem and a documentation-quality problem.

> And now, if
> named arguments are added, all of a sudden, you can't rename parameters
> without
> breaking code.
>
> I, for one, do not want to _increase_ the number of things that I
> can't change in code without breaking other people's code.  And at least
> with
> functions, I could rename them and leave a deprecated alias. With
> parameters, I
> don't have that option. A poorly named parameter would be set in stone
> unless
> the whole function were renamed or we were willing to break other people's
> code.
> Named arguments _decrease_ flexibility as far as the API goes.
>

I don't understand why people have such a problem with changed names in an API. Updating calls to use a new name is fucking trivial. How many seconds of terrible, miserable, back-breaking work did you have to suffer through to update your code for the new name changes in DMD 2.052? Granted it would be a problem if they were constantly changing everything's name around, but nobody does that even for private symbols.

And if you really want to be obsessive-compulsive about it, there's always this:

void foo(int a) {
    alias a b;
    ...
}


> On top of that, we would then have to worry about having high consistency
> in
> parameter names instead of just in function names. From the perspective of
> the
> library writer, this causes _more_ problems at _no_ benefit.

The "problem" is downright trivial, and as a library writer I'd certainly consider providing my users with a less error-prone API to be of benefit to me.


> From the perspective
> of the library user, it does provide some benefit, but I honestly do not
> think
> that
>
> func(x : 4, y : 5);
>
> is easier to read than
>
> func(4, 5);
>
> Sure, you have to know what func's parameters are, but you have to know
> that
> anyway.

But you no longer have to give a shit what their arbitrarily chosen order is. X and Y may have an obvious natural ordering, but a lot of things don't.


> Only now, with named arguments, you have to care about what their
> _names_ are in addition to what they're for. I do _not_ want to have to
> read
> code which uses named arguments. It's just more clutter and more
> intellectual
> overhead.
>

I do _not_ want to have to read code like this:

    box(10, 15, 5, 12)

Quiz: Could you tell which of the following that is without referring to any
docs?:
    - box(top, bottom, left, right)
    - box(top, right, bottom, left)
    - box(x, y, width, height)
    - box(x, y, rgb color, alpha)
    - box(x, y, z, hsl color)
    - box(id#, x, y, line thickness)
    - Or maybe the API author was stupid and made it something like
box(height, x, width, y)

One could argue the code is more likely like this:

    int x = 1;
    int y = 2;
    int width = 3;
    int height = 4;
    ...
    box(x, y, width, height)

But if you look at that, do you actually *know* the API is "x, y, width, height"? Nope. Could be a bug staring you right in the face.

Other people have addressed the "IDE API pop-up" issue.

Additionally, I do _not_ want to have to read code like this:

    Rect rect;
    rect.top = 1;
    rect.bottom = 2;
    rect.left = 3;
    rect.right = 4;
    box(rect)

(And yes, there's "with", but IMO that makes it even worse.) And note that that's only 4 params, not remotely "a ton". MS has a lot of APIs like that and even for small structs (*especially* for small structs) it quickly makes the user code a mess.

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:ikhtn9$2ea1$1@digitalmars.com...
> On 2/28/11 7:53 PM, Stewart Gordon wrote:
>> On 01/03/2011 01:29, Bekenn wrote:
>>> On 2/28/11 4:50 PM, Stewart Gordon wrote:
>>>> But one way around that would be to support
>>>> parameter aliases, which would also confer a few more benefits.
>>>
>>> Interesting idea. I think this might solve Jonathan Davis's main
>>> complaint; could you give
>>> an example of what syntax for that might look like?
>>
>> I don't know, but possibly
>>
>> void setColour(int colour alias color);
>>
>> and with a possibility of deprecating old names
>>
>> int find(string haystack deprecated alias s1, string needle deprecated
>> alias s2);
>>
>> Stewart.
>
> Don't know about others, but I think this is exactly the point where my "meh" detector goes off.
>

std.algorithm has far worse signatures. The main problem I have with the above is that it only solves a barely-existent "problem".

On 2/28/2011 9:24 PM, Nick Sabalausky wrote:
> std.algorithm has far worse signatures. The main problem I have with the
> above is that it only solves a barely-existent "problem".
>
>

Right, exactly.  Thinking about it some more, I don't really think the changing parameter name issue really justifies parameter name aliases.

Russel Winder <russel@russel.org.uk> wrote:

> The Python mechanism relies on the fact that despatch is by name and not
> by signature.  Languages that dispatch by signature will have
> significantly greater problems!

Hardly. Just like with default arguments, the compiler would add in the
missing stuff and use the simple signature. The parameter names would not
be part of the signature.

-- 
Simen

On 2/28/11 11:24 PM, Nick Sabalausky wrote:
> "Andrei Alexandrescu"<SeeWebsiteForEmail@erdani.org>  wrote in message
> news:ikhtn9$2ea1$1@digitalmars.com...
>> On 2/28/11 7:53 PM, Stewart Gordon wrote:
>>> On 01/03/2011 01:29, Bekenn wrote:
>>>> On 2/28/11 4:50 PM, Stewart Gordon wrote:
>>>>> But one way around that would be to support
>>>>> parameter aliases, which would also confer a few more benefits.
>>>>
>>>> Interesting idea. I think this might solve Jonathan Davis's main
>>>> complaint; could you give
>>>> an example of what syntax for that might look like?
>>>
>>> I don't know, but possibly
>>>
>>> void setColour(int colour alias color);
>>>
>>> and with a possibility of deprecating old names
>>>
>>> int find(string haystack deprecated alias s1, string needle deprecated
>>> alias s2);
>>>
>>> Stewart.
>>
>> Don't know about others, but I think this is exactly the point where my
>> "meh" detector goes off.
>>
>
> std.algorithm has far worse signatures. The main problem I have with the
> above is that it only solves a barely-existent "problem".

It's not the signature I was mehing about.

Andrei

On 01/03/11 08:08, Don wrote:
> 2. It introduces a different syntax for calling a function.
> foo(4, 5);
> foo(x: 4, y: 5);
> They look different, but they do exactly the same thing. I don't like
> that redundancy.

So, out of consistency, I suppose you must be against foreach, scope(exit) and every other kind of lowering?

On 2011-02-28 20:39, Steven Schveighoffer wrote:
> On Mon, 28 Feb 2011 14:32:52 -0500, Andrej Mitrovic
> <andrej.mitrovich@gmail.com> wrote:
>
>> On 2/28/11, spir <denis.spir@gmail.com> wrote:
>>> But this conflict already exists with the
>>> usage
>>> of ':' in dyn array notation
>>
>> Wait, when is ':' used with dynamic arrays?
>
> Think he meant AA.
>
> -Steve

Or static arrays.

-- 
/Jacob Carlborg

On 2011-02-28 21:44, Adam Ruppe wrote:
> Steven Schveighoffer:
>> But other than that, it still looks more verbose than should be
>> necessary.
>
> This is the real problem.
>
> We already have named arguments in today's D. You can do some stringof
> magic to get the parameter names and ParameterTypeTuple to assign them.
>
> I haven't written it, but there should be no blocker in combining these:
>
> void foo(int width, int height);
>
> auto args = NamedParameterTypeTuple!(foo);
>
> args.width = 10;
> args.height = 20;
>
> foo(args);
>
>
> But, that's just like the struct for length of code...
>
>
> If someone wanted to write the code to add the foo(width:10, height:10), I
> wouldn't likely object to it's inclusion. But, I
> don't see it as a big deal.

http://dsource.org/projects/orange/browser/orange/util/Reflection.d#L135

-- 
/Jacob Carlborg

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.

-- 
/Jacob Carlborg