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:={"...", "..."})

然而，由于编译器错误说 Named arguments cannot match ParamArray parameters ，这会失败，但是因为我已经为其他参数编写了命名参数，所以我不能让最后一个参数没有名字下面的方法，因为那时，另一个编译错误说 Named argument expected ：

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

我将此附加到与 Microsoft 相关的语言语法行为中的设计冲突，因为我可以看到他们让程序员解决此方案的唯一方法是这些不恰当的解决方案之一：< / p>

写一个公共参数（Optional参数）而不是ParamArray。
不要对任何参数使用命名参数。
忽略上面代码示例中最后一个参数的用法。

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

Answer 1

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

不，没有。有充分理由 - ParamArray是特定方法作者的考虑因素。命名参数是调用者方法的考虑因素。他们不会在相同的水平上运作，并且您已经链接到的文件表明他们有充分理由可以轻松共存。

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

通常，此类样本应与描述该方法的文档位于同一位置。如果他们都在同一页面上，那么如果用户感到困惑或需要查看，那么用户可以轻松找到该定义。

相反，决定在整个文档中使用命名参数比教育更容易混淆。您的示例代码看起来与其他代码示例明显不同。微软或大多数其他地方。这将直接让初学者感到困惑（如果他们还不熟悉命名参数），或者他们会形成错误的印象，例如＆＃34;我有使用命名参数这个图书馆。我想知道为什么？＆＃34;

使用ParamArray将命名参数冲突

1 个答案: