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.
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.
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.
enum bRepaint=true;
MoveWindow(... bRepaint)
