"Jonathan M Davis" <jmdavisp...@gmx.com> wrote in message
news:mailman.2069.1298937813.4748.digitalmar...@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.
