Naming parameters in script

[vcmohan]

Avisynth accepts in script calling functions with named parameters also without naming them as long as they are in correct order. This however creates problem when arrays are used. Incidentally arrays can not be named. In the following:
functionname(width = 720, height = 480, x= 90, y = 100)
can also be called as functionname(720,480,90,100) if the order of parameter named correspond to that actually used in the function code.
incase of
"fname", "ci*[width]i[height]i[x]i[y]i) if script call is
fname(1,2,3,4,720,480,x=90,y=100) it is not clear whether 720 and 480 are taken in to i+ array or assigned to width and height as was intended. This scheme is error prone.
I suggest that in 2.6 it may be made compulsory to make the names of named arguments be given in script. Should it not be possible to name even array parameters such as [table]i+ ? Vapoursynth does that and appears to be good.

[wonkey_monkey]

it is not clear whether 720 and 480 are taken in to i+ array or assigned to width and height as was intended.

I'd say the only logical expectation is that they'd be put into the array, and that if the programmer didn't intend this he should re-write it to be less ambiguous!

I suggest that in 2.6 it may be made compulsory to make the names of named arguments be given in script.

When you say "may be made" do you mean simply to make it compulsory all the time? Won't they cause a lot of broken-script headaches?

Should it not be possible to name even array parameters such as [table]i+ ?

I'd guess that the reason that isn't allowed is because there is no array type in the scripting language to pass to such a named parameter. How would you call a function with a named array parameter? fname(table=... ?)

I'd like to see something like the following made possible:

fname([1,2,3,4], 720,480, 90,100)
fname(table=[1,2,3,4], 720,480, 90,100)

a=[1,2,3,4]
fname(a, 720,480, 90,100)


with (what I assume is) the current procedure as fallback: if an array is expected next by the plugin, and an element of the correct type is found, place it in the array and continue reading parameters into the array until a named parameter is given.

Incidentally, this is why I put my arrays at the end of my plugin parameter strings ;)

[Gavino]

... with (what I assume is) the current procedure as fallback: if an array is expected next by the plugin, and an element of the correct type is found, place it in the array and continue reading parameters into the array until a named parameter is given.
I believe in the current procedure it will also stop reading if an argument incompatible with the array base type is found (whether named or not). This allows things like foo(1,2,3,true) when calling a function with a parameter type list of "i*b".

I agree it's the responsibility of the plugin writer to choose a parameter list that is unambiguously interpreted.

[vcmohan]

in the instance the parameter list is
c.*[ll]b[ss]s[ii]i
all parameters can be read as part of the .*
Possibly if the param list is
c.*bsi
one can get correctly.
In such cases if the parameters are named for convenience, the plugin writer checking for Defined() and ensuring it is, may be way out.

[StainlessS]

There is some advantage to putting array of type early in list of args, and forcing user to use the 'optional' argument name (for args following array, name no longer optional), it allows you to extend number of function arguments without breaking existing scripts.