允许将私有常量用作 public 方法的默认参数背后的想法是什么?
What's the idea behind allowing private constant to be used as default parameters for public methods?
令我惊讶的是,这个编译并运行:
class Program
{
static void Main()
{
DoSomething();
}
private const int DefaultValue = 2; // <-- Here, private.
public static void DoSomething(int value = DefaultValue)
{
Console.WriteLine(value);
}
}
方法是public,而默认值"redirects"为常量私有变量。
我的问题:
is/was 这个 "concept" 背后的想法是什么?
我的理解(直到今天)是,只有当所有其他 "referenced" 元素也是 public 时才能使用某些东西 public。
更新:
我刚刚对 class 进行了 ILSpy 反编译,发现:
static class Program
{
private static void Main()
{
Program.DoSomething(2);
}
private const int DefaultValue = 2;
public static void DoSomething(int value = 2)
{
Console.WriteLine(value);
}
}
因此,如果将私有常量作为默认参数进行处理,例如库,库的用户仍然看到默认参数。
当您使用 const 时,编译器会将所有出现的变量替换为实际值,因此您的代码与此相同:
public static void DoSomething(int value = 2)
What is/was the idea behind this "concept"?
这个想法是因为 const
值是静态的并且永远不会改变 - 您可以将它用作方法的可选参数的默认值,就像您可以使用普通值一样。来自 MSDN 的引述:
每个可选参数都有一个默认值作为其定义的一部分。如果没有为该参数发送参数,则使用默认值。默认值必须是以下表达式类型之一:
常量表达式;
new ValType() 形式的表达式,其中 ValType 是一个值
类型,例如枚举或结构;
形式为 default(ValType) 的表达式,其中 ValType 是一个值
类型。
My understanding (until today) was, that something public can only be
used if all other "referenced" elements are also public
从技术上讲是正确的。但是在你的场景中,两个成员都可以访问,因为它们是在同一个 class 中定义的,但是在我们的例子中, const
应该在 class Program
之外定义,它在内部是不可访问的class Program
.
常量变量在编译时被替换,因此它们从未真正存在于生成的程序集中。所以使用常量的代码实际上与直接使用常量值是一样的。好处就是你可以在别处复用这个常量,只需要在一个地方改变它。
现在,由于常量总是在编译时被替换,所以将它们设为 public 或私有的效果也很简单:它只影响其他类型可以在编译时访问它。因此,例如,如果您只想将该常量保持为当前类型,则使用私有常量会很有帮助,而 public 常量可以在整个应用程序中使用。
名字DefaultValue
是私人的,但号码2
仍然是号码2
。
因为 DefaultValue
是私有的,我们无法从 Program
外部访问 Program.DefaultValue
。大概我们不会特别想要。
而且因为我们根本不屑于定义 DefaultValue
,所以当我们研究 Program
的工作原理时,这可能是我们确实关心的事情。
所以当我们为 DoSomething
定义默认值时,可能有一些合乎逻辑的原因,为什么我们想要的值恰好与值 DefaultValue
.
相同
因此,能够在那里使用该常量可能是有益的,原因与我们发现常量在任何地方都有益的原因大致相同。
而且由于 DefaultValue
只是 Program
特定的表达方式 2
,所以我们没有理由不能这样做。
当然,元数据会将其反映为 2
而不是(对外部毫无意义的)DefaultValue
,但是如果 const
是 [=26] =] 无论如何(关于默认值的元数据只给出值,而不是它是否与任何定义的常量相关)。
所以没有缺点。
所以考虑到:
- 实施者有优势。
- 对用户没有任何不利,只是使用文字
2
。
- 防止它必须引入一个特殊规则作为规则的例外,即定义的常量可以在任何地方使用来自文字的常量值。
为什么不呢?
令我惊讶的是,这个编译并运行:
class Program
{
static void Main()
{
DoSomething();
}
private const int DefaultValue = 2; // <-- Here, private.
public static void DoSomething(int value = DefaultValue)
{
Console.WriteLine(value);
}
}
方法是public,而默认值"redirects"为常量私有变量。
我的问题:
is/was 这个 "concept" 背后的想法是什么?
我的理解(直到今天)是,只有当所有其他 "referenced" 元素也是 public 时才能使用某些东西 public。
更新:
我刚刚对 class 进行了 ILSpy 反编译,发现:
static class Program
{
private static void Main()
{
Program.DoSomething(2);
}
private const int DefaultValue = 2;
public static void DoSomething(int value = 2)
{
Console.WriteLine(value);
}
}
因此,如果将私有常量作为默认参数进行处理,例如库,库的用户仍然看到默认参数。
当您使用 const 时,编译器会将所有出现的变量替换为实际值,因此您的代码与此相同:
public static void DoSomething(int value = 2)
What is/was the idea behind this "concept"?
这个想法是因为 const
值是静态的并且永远不会改变 - 您可以将它用作方法的可选参数的默认值,就像您可以使用普通值一样。来自 MSDN 的引述:
每个可选参数都有一个默认值作为其定义的一部分。如果没有为该参数发送参数,则使用默认值。默认值必须是以下表达式类型之一:
常量表达式;
new ValType() 形式的表达式,其中 ValType 是一个值 类型,例如枚举或结构;
形式为 default(ValType) 的表达式,其中 ValType 是一个值 类型。
My understanding (until today) was, that something public can only be used if all other "referenced" elements are also public
从技术上讲是正确的。但是在你的场景中,两个成员都可以访问,因为它们是在同一个 class 中定义的,但是在我们的例子中, const
应该在 class Program
之外定义,它在内部是不可访问的class Program
.
常量变量在编译时被替换,因此它们从未真正存在于生成的程序集中。所以使用常量的代码实际上与直接使用常量值是一样的。好处就是你可以在别处复用这个常量,只需要在一个地方改变它。
现在,由于常量总是在编译时被替换,所以将它们设为 public 或私有的效果也很简单:它只影响其他类型可以在编译时访问它。因此,例如,如果您只想将该常量保持为当前类型,则使用私有常量会很有帮助,而 public 常量可以在整个应用程序中使用。
名字DefaultValue
是私人的,但号码2
仍然是号码2
。
因为 DefaultValue
是私有的,我们无法从 Program
外部访问 Program.DefaultValue
。大概我们不会特别想要。
而且因为我们根本不屑于定义 DefaultValue
,所以当我们研究 Program
的工作原理时,这可能是我们确实关心的事情。
所以当我们为 DoSomething
定义默认值时,可能有一些合乎逻辑的原因,为什么我们想要的值恰好与值 DefaultValue
.
因此,能够在那里使用该常量可能是有益的,原因与我们发现常量在任何地方都有益的原因大致相同。
而且由于 DefaultValue
只是 Program
特定的表达方式 2
,所以我们没有理由不能这样做。
当然,元数据会将其反映为 2
而不是(对外部毫无意义的)DefaultValue
,但是如果 const
是 [=26] =] 无论如何(关于默认值的元数据只给出值,而不是它是否与任何定义的常量相关)。
所以没有缺点。
所以考虑到:
- 实施者有优势。
- 对用户没有任何不利,只是使用文字
2
。 - 防止它必须引入一个特殊规则作为规则的例外,即定义的常量可以在任何地方使用来自文字的常量值。
为什么不呢?