[a101] UDFnObj .Call() excess params should throw maybe? Topic is solved

[swagfag]

im expecting this to throw but it doesnt. where are the rest of the params going

Code: Select all

class UDFnObj
{
	Call(arg1, arg2) {
		MsgBox arg1 '`n' arg2
	}
}

fn := new UDFnObj()

%fn%('ok', 'still ok', 'these', 'should', 'throw')

compare:

Code: Select all

fn('ok', 'still ok', 'these', 'should', 'throw', 'and they do')

fn(arg1, arg2) {
	MsgBox arg1 '`n' arg2
}

throws Too many params passed to function

[Helgef]

Passing too many parameters is tolerated; each extra parameter is fully evaluated (including any calls to functions) and then discarded.

src

[swagfag]

i didnt see this
is that a limitation of the current implementation or the actual intended behavior? i cant imagine the latter being the case. still think it should throw

[lexikos]

It was intended behavior. Before variadic calls, there was no way to call a function with a variable number of parameters, so dynamic calls were permitted to pass more than the function accepts.

It is still useful for calling callbacks where the callback author isn't required to define all parameters (like OnMessage, OnEvent, etc.) and the function object is not required to implement MaxParams accurately or at all. (I will probably add this to BoundFunc, but the function object is not required to be a standard one.)

Perhaps the default should be to throw, with some new syntax to permit surplus parameters. Catching the exception won't necessarily work as intended, since it could be thrown from within the function during an initially successful call.

[swagfag]

yes i was thinking "well, if i wanted to have it work with varargs, id have defined it as such, a la Call(arg1, arg2, theRest*) {", but now i see it behaves that way for historical reasons
thank u for ur input, both of u

[lexikos]

The point is not to "work with varargs". Varargs would just be a workaround for the restriction placed by parameter count validation.

Normally, there is one function definition and multiple callers. The author of the function decides which parameter it accepts and what they mean, so passing more is not meaningful. The author of the function can decide parameters are optional, and give them default values.

With callbacks, there is one call site and many function definitions. The author of the library which contains the call site decides what the parameters mean. When calling the callback, there is no way to say "these parameters are not required to be handled". Instead (with full parameter count validation), the callback author is required define every parameter, or to accept a variable number of parameters even though it is known in advance exactly how many the function will use.

In some languages, the callback would need to match the predefined signature exactly.

[nnnik]

Which is preferable since an unmatching parameter count is among the safest indicators for errerneous code. The convenience of callbacks seems completely irrelevant when put into that context.

[lexikos]

Suggestion implemented in v2.0-a103.