java - 为什么 Java 8 使用 null 时，Guava 的Optional 使用抽象类？

Question

当Java 8发布时，我期望发现它的Optional实现与Guava的基本相同。从用户的角度来看，它们几乎是相同的。但是Java 8的Optional在内部使用null来标记一个空的Optional，而不是使Optional抽象并有两个实现。除了 Java 8 的版本感觉不对(你只是通过隐藏你实际上仍在使用它们的事实来避免空值)之外，每次你想访问它时检查你的引用是否为空不是效率较低吗？而不是仅仅调用一个抽象方法？也许不是，但我想知道他们为什么选择这种方法。

Answer 1

也许 Google Guava 的开发者想要开发一种更接近函数世界的习惯用法:

datatype ‘a option = NONE | SOME of ‘a

在这种情况下，您可以使用模式匹配来检查类型选项实例的真实性质。

case x of
    NONE => //address null here
  | SOME y => //do something with y here

通过将 Option 声明为抽象类，Google Guava 遵循了这种方法，其中 Option 表示类型 ('a option)，以及 的子类>of 和 absent 将表示此类型的特定实例(SOME 'a 和 NONE)。

Option的设计为thoroughly discussed in the lambda mailing list 。用布莱恩·戈茨的话来说:

The problem is with the expectations. This is a classic "blind men and elephant" problem; the thing called Optional has different "essential natures" to different viewpoints, and the problem is not that each is not valid, the problem is that we're all using the same word to describe different concepts (more precisely, assuming that the goals of the JDK team are the same as the goals of the people you condescendingly refer to as "those familiar with the concept."

There is a narrow design scope of what Optional is being used for in the JDK. The current design mostly meets that; it might be extended in small ways, but the goal is NOT to create an option monad or solve the problems that the option monad is intended to solve. (Even if we did, the result would still likely not be satisfactory; without the rest of the class library following the same monadic API conventions, without higher-kinded generics to abstract over different kinds of monads, without linguistic support for flatmap in the form of the <- operator, without pattern matching, etc, etc, the value of turning Optional into a monad is greatly decreased.) Given that this is not our goal here, we're stopping where it stops adding value according to our goals. Sorry if people are upset that we're not turning Java into Scala or Haskell, but we're not.

On a purely practical note, the discussions surrounding Optional have exceeded its design budget by several orders of magnitude. We've carefully considered the considerable input we've received, spent no small amount of time thinking about it, and have concluded that the current design center is the right one for the current time. What is surely meant as well-intentioned input is in fact rapidly turning into a denial-of-service attack. We could spend endless time arguing this back and forth, and there'd be no JDK 8 as a result. I'm sure no one wants that.

So, let's keep our input on the subject to that which is within the design center of the current implementation, rather than trying to convince us to change the design center.