On Tue, 14 Jun 2011 12:58:30 +0300, KennyTM~ <kenn...@gmail.com> wrote:
And yet, with loc.x, myWin.width etc, you don't need to check the
definition to know those should be coordinates and widths.
loc.x on the caller side, it has no idea about function signature, and you
don't know if it was 10th or 2nd argument in function.
// definition
fun(int x, int y) {
}
// call
fun(x, y) // you need to check the definition if you think something wrong
with parameters the second time you come here
fun(y, x) // same
fun(x:x, y:y) // you know there is nothing wrong with parameters
fun(y:y, x:x) // same
You don't need to abandon hybrid to enable reordering. Ary's suggestion,
for example, allows positional and named arguments to coexist.
Allows reordering by introducing two new order restrictions which i still
had trouble understanding, sorry Ary :)
Why do you need to check the function definition when you see 'moveTo(x,
y)'?
Same question, why do you need named arguments?
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);
Again, they are variables you get on the caller side, they got no idea
about function signature.
Also i don't understand why some think allowing hybrid calls has any
merit. Just search "named arguments" and first thing you'd see is calls
with all arguments named, no exception. Allowing unnamed arguments and
named arguments in one call doesn't make any sense to me, it is almost
opposite to the reasons named arguments designed for, you don't even need
to talk about its drawbacks like the complications and confusions.
