Cui*_*崔鹏飞 0 c# scala language-design optional-parameters default-parameters
本博客的最后一部分解释了以下内容:http://lostechies.com/jimmybogard/2010/05/18/caveats-of-c-4-0-optional-parameters/
但我仍然想知道为什么.
我最近遇到了Scala的默认参数.
在Scala中,被调用者为具有默认值的参数提供实际值.因此,不必重新编译所有调用者以使用更新的默认参数值.
如果Scala可以做到,我猜C#也可以做到.
所以为什么？他们为什么设计它容易出错？
编辑:
容易出错可能过于强烈,所以我的问题更像是这样:
为什么它的设计方式是默认参数的版本控制不会影响调用者？
从Eric Lippert本人的话来说:
也就是说,他们认为默认值以某种方式"烘焙"到 被调用者.
实际上,默认值被烘焙到调用者 ; 被呼叫方的代码不受影响,呼叫者变为
M("{0}", false);这一事实的结果是,如果更改库方法的默认值而不重新编译该库的调用者,则调用者不会仅因为默认值更改而更改其行为.如果您发布的方法M的新版本将默认值更改为true,则对这些调用方无关紧要.在重新编译具有一个参数的M的调用者之前,它将始终传递false.
这可能是一件好事.将默认值从false更改为true是一个重大变化,可以说现有的调用者应该与那个重大变化隔离开来.[强调我的]
这是一个相当严重的版本问题,也是我们在向C#添加默认参数时推迟了这么长时间的主要原因之一.这里的教训是仔细考虑长期考虑的情景.如果您怀疑要更改默认值并且希望调用者在不重新编译的情况下获取更改,请不要在参数列表中使用默认值; 进行两次重载,其中参数较少的一次调用另一次.
至于为何在Scala中有所不同:也许C#中存在技术上的限制.如果你查看可选参数的4个帖子,你会注意到他们有许多角落要记住.
如果它不是技术限制,它很可能是一个管理问题.正如经常 指出的那样:
以下是我们设计C#4的方法.
首先,我们列出了我们可以考虑添加到语言中的每个可能的功能.
然后我们将这些功能分解为"这很糟糕,我们绝不能这样做","这太棒了,我们必须这样做","这很好,但这次不要这样做".
然后我们看看我们有多少预算来设计,实施,测试,记录,发布和维护"必备"功能,并发现我们超出预算100%.
因此,我们将一堆东西从"得到的"桶中移到了"好有"的桶中.
我们花费在设计,实现,测试,记录或维护好的特征X上的每一分钟都是我们不能花费在令人敬畏的特征A,B,C,D,E,F和G上的一分钟.我们必须无情地优先考虑,以便我们只尽可能做到最好的功能.索引属性会很好,但是好的并不是任何地方甚至接近足够好以实际实现.