AutoHotkey Community

Instead of evaluating then silently discarding extra parameters, it might be more useful to use them as local variables instead. This would allow calling parameters by name.

So instead of the following workaround inolving a global,

you could do this:

What is the reason for that? Is it just to omit variables?
I think you would get confused very quickly.

If I have to pass many different variables I use that technique

_________________
AHK_H (2alpha) AHF TT _Struct WatchDir Yaml _Input ObjTree RapidHotkey DynaRun

1) What's it got to do with dynamic function calls?
2) The proposed syntax conflicts with assignment.

Only dynamic function calls support more than necessary parameters currently. Actually maybe nondynamic function calls should also support unnecessary parameters.

perhaps a different syntax to accomplish the same thing to avoid the conflict with assignment.
such as

yes, it would allow you to omit variables... that's what makes it named parameters different from just optional parameters at the end, like what is currently allowed.

Edit:
Actually, I don't see the conflict with assignment. Lexikos could you please explain?

Try this code.

byref parameters are not local anyways.
The proposed syntax is for non-byref parameters.

In a related note, I'm wondering if it's hard to implement to allow missing/omitting optional parameters.

Another syntax suggestion:

Extending the local keyword at function calls.

And for seans suggestion

introducing new variable for use in different situations (universal). In example it holds a special content, everytime Ahk see this content it does appropriate action to current context.

I implemented it in a private build a while back, but was reluctant to add it to AutoHotkey_L. Basically I did this:

• Change load-time validation to allow empty parameters. (I chose to disallow blank parameters at the end of the parameter list since it wasn't useful; there may have also been technical reasons.)
• Change the infix to postfix conversion phase to put blank_token into the postfix array when a comma is encountered in a function's parameter list, directly preceded by another comma. blank_token represented an empty string, but was also a unique (pointer) value used to identify "omitted" parameters.
• Change script function-calling at run-time to assign a parameter its default value if the corresponding token on the stack == &blank_token (i.e. the parameter was ,, omitted).

There didn't seem to be any simple way to disallow it for required parameters, so in that case (or for built-in functions), ,, was treated as ,"",.

If the actual function were known at the point the comma is processed, it could prevent omitting of required parameters and also insert the actual default value instead of requiring the '== &blank_token' check for every parameter of every function call.
It was just an example of why you'd want to perform assignment in-line. It is perfectly legitimate to do that when the parameter is not ByRef. There are also other, less important reasons not to implement syntax which can apply only to non-ByRef parameters.

Why should named ByRef parameters be excluded?

There is an easy way to avoid any conflicts with existing valid syntax: omit =.
(This has probably been suggested before.)

OK, fine, my query was a casual one anyway as the workaround is quite simple, just set simple one like "" as the default value then redirect it to the genuine one inside the function. I asked it nevertheless 'cause I sometimes felt ridiculous about I was doing.

I presented my workaround here and also suggested this around 2 years ago on Developers forum.


I sometimes wish this, but named parameters are much much better idea. The problem with above is that you will soon have "InputBox" symptom:


About named parameters the problem with assignment can be fixed with literals:


since you cant assign to literal.

There are dozens of ways to do it, lets give examples on:

Declare:

Use



To me, the best looking are 3+1 or 1+1

Here are some examples on 1+1:


So, in short, function argument list consist of 2 parts, unnamed part that is determined by position and named part. Parts can not be mixed as constructs like the following are meaningless:

_________________

How about that?
The only disadvantage is you cannot use literal "" inside your variables.

_________________
AHK_H (2alpha) AHF TT _Struct WatchDir Yaml _Input ObjTree RapidHotkey DynaRun

That depends on the number of parameters, of course. As I myself needed to skip just 1 or 2 parameters mostly, missing parameter is more handy to me. BTW I'm not against named parameter.

er.. I would term it as "Limitation"

I am rewriting my InternetFileRead() and cooked up the following method ( much similar to yours ) for overriding values of static and local variables.


The limitations are:
Var should not contain = or ,
Var name should not be _overrides or _

Please update http://rosettacode.org/wiki/Named_parameters#AutoHotkey with details of all the limitations of the work-alike posted.

Thanks.