【问题标题】:Whats wrong with non nullable objects?不可为空的对象有什么问题?
【发布时间】:2009-01-28 09:49:38
【问题描述】:

我最近一直在研究 DbC 和 Spec#,它们似乎支持不可为空的对象。不幸的是,Spec# 似乎已被放弃。

  1. Spec# 似乎内置了很多不错的语言功能,为什么它被放弃了?
  2. 默认情况下让所有对象都不可为空会有什么问题,所以你必须写 int?,字符串?甚至MailMessage?如果你真的想要一个可为空的对象?
  3. 我在这里看到了一种 Sql 类比 你可以在哪里查看课程 可以为空或不可为空的属性 可以为空。你能不能把 对属性的限制 可以用sql表列吗?

我没有看到将此类功能内置到语言中的问题。有人能告诉我吗?

【问题讨论】:

    标签: design-by-contract non-nullable spec#


    【解决方案1】:

    您是否看到新的Contracts framework 将成为.NET 4.0 的一部分?

    使它成为一个库而不是语言功能的好处是它可以立即以所有语言提供,而无需语言团队的任何工作。显然也有缺点……

    链接:

    说了这么多,我希望能够写:

    public Stream! Foo(string! x)
    

    同样,表明 Foo 不能接收空引用,也不会返回一个。我认为,为 just 这种类型的合同增加一点语法会很方便。

    【讨论】:

    • 我见过,它似乎有编译器检查少,代码臃肿多的缺点。也许他们可以将这个内置到 c#4.0 并提供其他语言的框架?
    • 虽然检查不在编译时完成,但它们作为构建后步骤完成,因此您不必等到实际运行编码。看看它的效果会很有趣,但老实说,我很乐意拥有它。
    • 感谢链接。我看到了 PDC 视频,我可以想象我经常使用合同框架。仍然 Spec# 看起来好多了:)
    • 好消息是,在联系人框架隐藏后,语言团队可以定义新语法(例如奇妙的 Spec# 模式)并由编译器完成检查。毕竟“from a in myObjects where a.IsProp select a.Name”被编译成 myObjects.Where(a=>a.IsProp).Select(a=>a.Name) ...即使这比真正的静态调用看起来就像没有扩展方法。
    • @Joan:如果不使用不可为空的引用,很难说默认应该是什么——这基本上取决于它们的工作方式。但也许吧。
    猜你喜欢
    • 1970-01-01
    • 2021-12-06
    • 1970-01-01
    • 2018-11-01
    • 1970-01-01
    • 1970-01-01
    • 2021-12-01
    • 1970-01-01
    相关资源
    最近更新 更多