Unhelpful / doubled error message

bgrommes

From this I cannot tell what it's on about, and in any case, the message is doubled:

It is possible that the (currently untested) Path.Combine method (Path being a module), which takes ParamArray values() As String as its argument, has something to do with it, and it's just reporting on the wrong line. Although this error wasn't displayed right after I typed in the Path.Combine() call.

I realize there's probably some construct around FileSystemItem using Child that would get me the FileSystemItem instance without having to construct the full path, but I need the full path for other things and there will be times I won't need it to create a FileSystemItem. Hence my partial reproduction of the static .NET Path class.

ETA: This was not resolved by running Analyser but after switching away to edit something else and coming back, the error gutter marker is now on line 2. So I think this also ends up being either a bug in calling a method that takes a ParamArray, or a misunderstanding on my part about how it's supposed to work.

Path.Combine itself treats values() as an Array(Of String) and produces no errors.

If I change the call to the following, it works:

Var fullPath As String = Path.Combine([_filePath, _fileName])

But this is not my understanding of variadic parameters. I might as well just drop the ParamArray modifier. My understanding is you pass any variable number of string arguments and it is seen by the receiver as an Array(Of String).

Garry

Thanks for reporting this. I’ve confirmed and fixed it: https://feedback.objo.dev/bug/887

Your understanding of ParamArray is correct. Given:

Function Combine(ParamArray values() As String) As String

this call should accept two individual strings:

Path.Combine(_filePath, _fileName)

The compiler was incorrectly checking each argument against the parameter’s internal storage type, Array(Of String), rather than its element type, String. It therefore produced the same misleading error once for each argument, explaining the apparently doubled message.

The array-literal workaround:

Path.Combine([_filePath, _fileName])

wasn’t semantically correct: it passed one array as a single variadic element rather than passing two string elements.

bgrommes

Garry When I said that Path.Combine([filePath,fileName[) "worked" I meant "did not produce an error message" in Studio. I haven't actually tested it yet. It would work if ParamArray were being ignored in methods where it's declared, which apparently isn't the exact problem.

A relevant question. The reference source for .NET implements Path.Combine() (and Path.Join()) as a series of overloads taking 1, 2, 3 or 4 strings, AND as a variadic to handle 5+ arguments. I've seen this pattern in other code bases and assume it is to avoid the overhead of internally creating the variadic array from the arguments on typical calls. Would this apply in Objo as well as a good practice for library code / hot paths?

Garry

Yes. The same consideration applies in Objo. A call to a ParamArray method currently materialises an Array containing the variadic arguments, so fixed-arity overloads can avoid that allocation.

For a small, potentially frequent routine such as Path.Combine, providing two-, three- and four-string overloads with a ParamArray fallback seems sensible. The caveat is that the fixed overloads only help if they don’t immediately create an array themselves to delegate to the variadic implementation.

I wouldn’t consider this a general rule for every API, though. ParamArray is usually clearer and more convenient; fixed overloads are mainly worthwhile for library code where the method is likely to be called frequently or profiling shows the allocation matters.

bgrommes

Garry Thanks, that confirms what I was thinking was most likely true.