【问题标题】:What are the key differences between Java 8's Optional, Scala's Option and Haskell's Maybe?Java 8 的 Optional、Scala 的 Option 和 Haskell 的 Maybe 之间的主要区别是什么?
【发布时间】:2014-04-17 14:44:04
【问题描述】:

我已经阅读了一些关于 Java 8 即将推出的 Optional 类型的文章,我试图理解为什么人们一直认为它不如 Scala 的 Option 强大。据我所知:

  • 使用 Java 8 lambda 的高阶函数,例如 map 和 filter。
  • 一元平面地图
  • 通过 getOrElse 类型函数实现短路。

我错过了什么?

【问题讨论】:

  • "...worse than" - 这听起来像是一个主观的讨论。但是,我还没有做任何事情。让我们看看这是怎么回事。
  • 根据this post,他们不会更新所有API 以使用它(例如List.Get())。其余的可以在here找到。
  • 任何使用“强大”这个词的帖子都不值得你去好奇。
  • 另外,您仍然可以拥有nullOptional/Maybe 的全部意义在于引用不能null,因此允许它们(Java 必须,为了向后兼容)已经减少了一些好处。
  • @AlexeyRomanov 除了 Scala 标准库在很大程度上设计为使用 null,因此惯用的 Scala 代码仅在涉及 Java 互操作时处理 null。而在惯用的 Java 中,一旦 Optional 到达......您仍然必须明确检查所有内容是否为 null,因为您的大多数值可能来自不喜欢 Optional 而不是 null 的代码。

标签: java scala haskell


【解决方案1】:

我想到了一些可能性(OTOH,我还没有看到人们真的这么说,所以他们可能意味着别的):

  1. 无模式匹配。

  2. 不等同于 Scala 的 fold 或 Haskell 的 fromMaybe:您必须改用 optional.map(...).orElseGet(...)

  3. 没有单子语法。

我自己也不会称这些“功能较弱”,因为你可以用相应的 Scala/Haskell 类型表达你所能表达的一切;这些都是简洁/可用性问题。

【讨论】:

  • "你必须改为 optional.map(...).orElseGet(...)" - 这不是一回事,因为“else”部分会在任一个可选时触发empty 或 optional.map(...) 为空:)
【解决方案2】:

OptionalMaybe 有效地对应。 Scala 将NoneSome[A] 作为Option[A] 的子类,这可能更直接地与Java 相媲美,因为Java 也可以做到这一点。

大多数其他差异要么与在 Haskell/Scala 中处理 Maybe/Option 的易用性有关,因为 Java 作为一种语言的表达能力较差,要么与 Maybe/@ 的使用一致性有关。 Haskell/Scala 中的 987654329@,其中类型提供的许多保证和便利只有在大多数库同意使用可选类型而不是 nulls 或异常时才会生效。

【讨论】:

    【解决方案3】:

    在大多数情况下,它们是等价的;主要区别在于 Scala 很好地集成到了 Scala 中,而 Java 很好地集成到了 Java 中。

    在我看来,最大的不同是 Java 是 value-based class.,这对 JVM 来说是新事物。目前,基于值的类和常规类之间没有真正的区别,但这种区别为 JVM 运行时消除 Java 对象开销铺平了道路。换句话说,future JVM 可以将 Optional 代码重写为如何处理 null 的指令,而不是为 Optional 对象分配内存。

    Scala 对value classes 做了类似的事情,尽管它是通过在编译器中而不是在 JVM 中拆箱类型来完成的,并且它的使用是有限的。 (Option 不是值类。)

    【讨论】:

      猜你喜欢
      • 2014-03-09
      • 2017-03-18
      • 2014-12-19
      • 2010-10-17
      • 1970-01-01
      • 1970-01-01
      • 2015-08-22
      • 2015-08-06
      • 2011-03-06
      相关资源
      最近更新 更多