On Jun 14, 11 16:39, so wrote:
On Tue, 14 Jun 2011 11:23:12 +0300, KennyTM~ <kenn...@gmail.com> wrote:
On Jun 14, 11 14:46, so wrote:
On Tue, 14 Jun 2011 09:18:42 +0300, KennyTM~ <kenn...@gmail.com> wrote:
I'd rather have no reordering and allow hybrid call. Named argument is
useful for specifying the nature of an argument. If the type is clear
for all but one argument, the rest is just noisy redundant info.
fun(bool, bool, bool, bool, bool...)
Isn't the type clear for every argument here?
By "type" I mean the purpose of an argument, e.g. the first 'int' in
MoveWindow is an x-coordinate, the second is a y-coordinate, etc.
Sorry I don't know of a better term. When what one argument does is
clear for the caller, forcing NA on it just annoys the programmer.
This is the whole point of NAs, it is not clear, you need to check the
function definition whenever you read the call.
And yet, with loc.x, myWin.width etc, you don't need to check the
definition to know those should be coordinates and widths.
e.g.
MoveWindow(hWnd, loc.x, loc.y, myWin.width, myWin.height,
bRepaint:true);
is no worse than
MoveWindow(hWnd:hWnd, X:loc.x, Y:loc.y,
nWidth:myWin.width, nHeight:myWin.height, bRepaint:true);
Reordering is important an example:
fun(int a, int b=2, int c=3)
If you want to name c but not b what are you going to do?
That's skipping, not really reordering. 'a' still precedes 'c'. Also,
I'm not against reordering, but I'm against using reordering as a
reason to abandon hybrid.
It is not a reason to abandon hybrid, it is a consequence of abandoning it.
You don't need to abandon hybrid to enable reordering. Ary's suggestion,
for example, allows positional and named arguments to coexist.
Named arguments isn't something to save typing.
Also the first version of the MoveWindow indeed worse than the second,
which again i think requires no explanation.
No, please explain. What does the extra hWnd, X, Y, nWidth, nHeight
buy, when the respective arguments already show what they are?'
Matching, with fun(x:x, y:y) or fun(y:y, x:x) you are done, you don't
ever need to check function definition again.
With your reasoning you don't need named arguments at all.
Why do you need to check the function definition when you see 'moveTo(x,
y)'?
enum bRepaint=true;
MoveWindow(... bRepaint)
Non sequitur. In my MoveWindow example hWnd, loc and myWin are assumed
to be variables you got from elsewhere. The names of these variables
already provide the semantics to the readers, making NA for those
arguments redundant. If they were constants it's nothing wrong with
MoveWindow(hWnd, X:0, Y:0, nWidth:200, nHeight:200, bRepaint:true);
