Named parameters

[iseahound]

Question about named parameters syntax support in the future:

You can do this:

Code: Select all

Color(alpha: 1, red: 102, green: 205, blue: 170)

but if you decide to go with an equals sign like Python you'll have two classes of equals (= for named parameters, := for expressions)

Or the Javascript way of forcing the use of an object:

Code: Select all

Color({alpha: 1, red: 102, green: 205, blue: 170}) ; optional * at the end?

This isn't a request for named parameters. Just wanted to make sure the : choice was thought through. Personally, I've always read : as "in", so I like the current approach.

[lexikos]

This appears to have nothing to do with typed properties, so I have moved the post.

You post seems to contain one or more presumptions and contradictions, and I'm not sure exactly what your question is. You prefaced your post with "Question" but then didn't ask one.

[iseahound]

1.

Code: Select all

Color(alpha: 1, red: 102, green: 205, blue: 170)

2.

Code: Select all

Color({alpha: 1, red: 102, green: 205, blue: 170}*)

3.

Code: Select all

Color({alpha:=1, red:=102, green:=205, blue:=170})

4.

Code: Select all

Color({alpha=1, red=102, green=205, blue=170})

My question: Have you given some thought to the future syntax of named parameters? Since the typing relation could in theory be extended to DllCall("some_fn", a : i32, b : u32). (Not sure)
1. Syntax possibly taken by typed properties?
2. Should work.
3. Has side effects. Now red is set to 102 for the rest of the script.
4. = Abandoned since v1
5. Not have named parameters, they really aren't necessary.

[V2User]

1.

Code: Select all

Color(alpha: 1, red: 102, green: 205, blue: 170)

2.

Code: Select all

Color({alpha: 1, red: 102, green: 205, blue: 170}*)

3.

Code: Select all

Color({alpha:=1, red:=102, green:=205, blue:=170})

4.

Code: Select all

Color({alpha=1, red=102, green=205, blue=170})

My question: Have you given some thought to the future syntax of named parameters? Since the typing relation could in theory be extended to DllCall("some_fn", a : i32, b : u32). (Not sure)
1. Syntax possibly taken by typed properties?
2. Should work.
3. Has side effects. Now red is set to 102 for the rest of the script.
4. = Abandoned since v1
5. Not have named parameters, they really aren't necessary.

I want to add 5. :

Code: Select all

obj1{alpha: 1, red: 102, green: 205, blue: 170}.Color()
{base:obj1,alpha: 1, red: 102, green: 205, blue: 170}.Color()

See this post: viewtopic.php?f=37&t=112410

[RaptorX]

My question: Have you given some thought to the future syntax of named parameters? Since the typing relation could in theory be extended to DllCall("some_fn", a : i32, b : u32). (Not sure)
1. Syntax possibly taken by typed properties?
2. Should work.
3. Has side effects. Now red is set to 102 for the rest of the script.
4. = Abandoned since v1
5. Not have named parameters, they really aren't necessary.

I like the Function(a:10, b:20) syntax, I would love to see it extended to DllCalls for sure.


I do have a comment on 3. and 5.

3: I would definitely not want external side effects when passing an argument like that.
that would be like saying that this code would change the global variable, which is completely unexpected:

Code: Select all

color := 'red'
HEX('blue')
msgbox color ; we expect that this should not be changed by the above call

HEX(color: 'red')
msgbox color ; this would be the exact same call, so no side effects should be expected I think
return

HEX(color)
{
	switch color
	{
	case 'red': return 0xFF0000
	case 'green': return 0x00FF00
	case 'blue': return 0x0000FF
	}
}

5: I completely disagree, named parameters allow you to pass the parameters in whatever order makes sense to you, not in the exact same order the function is defined as. And It allows you to omit parameters you dont need as well.

hopefully we could do this at some point:

Code: Select all

; ignore the title parameter
Msgbox(text: "This is a test", options: "Iconi")

; invert the title and text parameters cause i like it that way
Msgbox(title: "error", text: "this is an error")

; not sure if mixing named parameters with positional parameters is feasible though, just a nice wish
 ; the third parameter is in the correct position, so i wouldnt need to name it.
msgbox(title: "a nice title", text: "some text", "iconX")

I know that named parameters probably wont be available for built-in functions right away but the most important way this helps a lot is when you have functions that have many optional parameters... you definitely simplify your calls like this:

Code: Select all

; SplitPath path,,&oDir,,,&oDrive <-- I really hate this
SplitPath path, Dir: &oDir, Drive: &oDrive ; <--- wouldnt this be awesome?

I worked with some microsoft com objects and some of their functions have 13-14 parameters
you could imagine all the empty commas in that code and you just have to put one less and the code wont work because you are in the wrong parameter.

So named parameters are one of the things im more excited about.