• unnames args cannot follow named args

Posted: **Fri Jan 26, 2007 12:40 am**

Im just curious why this is so. I mean what difference would it make (apart from it not compiling) if i have something like

Code: Select all

GFAddButton(gump, x, y, w, l, btn_type:=GF_PAGE_BTN, 4);

compared with

Code: Select all

GFAddButton(gump, x, y, w, l, GF_PAGE_BTN, 4);

Posted: **Fri Jan 26, 2007 5:26 am**

I'm not sure why some code is like that, either. I don't think that the difference has any change on the result of the code anyways, so the best I can figure is that it's for the coder's convenience (knowing what parameters they are passing should they want to come back and see the code later without having to refer to the manual.)

Posted: **Fri Jan 26, 2007 10:15 am**

Maybe I am misunderstanding the question.

Code: Select all

SOME_CONST := 1;

function Foo(arg:=SOME_CONST)
  return arg;
endfunction

// this will return 1
Foo()

// this will return 2
Foo(2)

This is how you define defaults for function arguments. The default is used if nothing is passed.

Posted: **Fri Jan 26, 2007 2:17 pm**

what i mean is why doesn't it compile in the first place.

This compiles fine

Code: Select all

GFAddButton(gump, x, y, w, l, GF_PAGE_BTN, 4);

and so does this

Code: Select all

GFAddButton(gump, x, y, w, l, btn_type:=GF_PAGE_BTN, btn_value:=4);

however this spits out the unnamed args cant follow named args error

Code: Select all

GFAddButton(gump, x, y, w, l, btn_type:=GF_PAGE_BTN, 4);

So i guess im just asking why POL doesn't like it when it doesn't seem like it should matter at all.

Posted: **Sun Jan 28, 2007 4:08 am**

In order to understand this, you have to understand what named arguments do... why are you using them? You might have a reason for using them, but it may not be 'the' reason.

The reason for named arguments is so that you can pass the arguments in any order you like, and not just in the order they are defined in the function.

For example, compile and run this as a dot-command. You will find you get "hi" as a system message:

Code: Select all

use uo;

program Testing(who)
	var huh := "hi";
	Hello(what := huh, char:=who);
endprogram

function Hello(char, what)
	SendSysMessage(char, what);
endfunction

Note that my function, 'hello', does not have optional parameters. Named parameters have basically NOTHING to do with optional parameters, directly. However, sometimes you might want to use them to help you with optional parameters. Take this example:

Code: Select all

use uo;

program Testing(who)
	var huh := "hi";
	Hello(things := 1, char:=who);
endprogram

function Hello(char, what := "hi", things := 0)
	if (things)
		SendSysMessage(char, what);
	endif
endfunction

I am using named parameters here to avoid the need to define the 'what' parameter.

Again, this is the important part: Named parameters exist to let you order your parameters any way you wish - they do not have anything directly to do with optional parameters. It just so happens that defining named parameters in a function definition/prototype has the same syntax as using named parameters in a function call.

Once the compiler sees a named parameter in a call to a function, all bets are off as far as the order of parameters having anything to do with which are what... so while YOU might think it 'knows' what goes where... it does not know. When you pass a named parameter, you MUST name any subsequent parameters, as well.

All of that said, I find the use of named parameters to generally be very bad form. They invite confusion, IMO.

Posted: **Sun Jan 28, 2007 5:56 pm**

As a general rule I agree with you Marilla. The only place I find myself cheating and using named parameters is when using the POL functions where the realm parameter has been (IMO) kluged onto the end of the parameter list folllowing flag and other defaulted parameters instead of it being placed where it belongs, right after the z location parameter.

[Edit] Oh yes and in the SendSysMessage function when I wish to specify a colour and do not want to throw in the font parameter. I admit that's the biggest cheat I do.
*grins*

Posted: **Tue Jan 30, 2007 1:21 am**

IMO, it's "acceptable" to use named parameters to "skip" an optional parameter, as you note. But never to change the order of parameters. Though in a way, using it to 'skip' a parameter is the same thing... sorta. hehe. But you get the point, and I agree.