使用命名参数与ParamArray进行冲突

Question

我编写了一个具有以下参数的方法：

Sub MethodName(ByVal paramName1 As String,
               ByVal paramName2 As String,
               ByVal paramName3 As String,
               ByVal ParamArray lastParam As String())
End Sub

在上面的代码中，参数的名称只是一个例子，在我的真实代码中，参数的名称是描述性的名称，我将使用命名参数来编写可理解的编码，所以按照上面的示例方法，我将编写如下内容：

MethodName(paramName1:="...",
           paramName2:="...",
           paramName3:="...",
           lastParam:={"...", "..."})

但是，如果编译器错误地说是命名参数不能匹配ParamArray参数，但是由于我已经为其他参数编写了命名参数，那么我就不能让最后一个参数以下面的方式没有名称，因为那样的话，另一个编译器错误就是预期命名参数。

MethodName(paramName1:="...",
           paramName2:="...",
           paramName3:="...",
           {"...", "..."})

我将此归因于与Microsoft相关的语言语法行为中的设计冲突，因为我看到让程序员解决此场景的唯一方法是这些不太好的解决方案之一：

• 编写公共参数( Optional参数)而不是ParamArray。
• 不要为任何参数使用命名参数。
• 忽略上面代码示例中最后一个参数的使用。

也许存在另一种我所缺少的解决方案来保留带有命名参数的ParamArray？

Answer 1

也许还存在另一种解决方案，我缺少它来保存带有命名参数的ParamArray？

不，没有，而且有充分的理由-- ParamArray是特定方法的作者的一个考虑因素。命名参数是方法调用者的考虑因素。它们不以相同的“级别”操作，您已经链接到的文档表明，它们不能很容易地共存是有充分理由的。

在构建API帮助文件时，您更愿意使用初学者代码示例中的命名参数来表示参数名，以便更友好地理解每个参数的用途。

通常，这样的样本应该与描述方法的文档放在一起。如果它们都在同一个页面上，那么用户可以很容易地再次定位定义，如果他们感到困惑或需要查看它。

相反，决定在文档中使用命名参数的可能性更大，而不是教育。您的示例代码将明显不同于其他代码示例，例如Microsoft或其他任何地方的代码示例。这将立即混淆初学者(如果他们还不熟悉命名参数)，或者他们会形成错误的印象，如“我必须使用这个库命名的论点。我想知道为什么？”