35

vals not (?) 在单例对象中自动成为 final的原因是什么？例如

object NonFinal {
   val a = 0
   val b = 1

   def test(i: Int) = (i: @annotation.switch) match {
      case `a` => true
      case `b` => false
   }
}

结果是：

<console>:12: error: could not emit switch for @switch annotated match
          def test(i: Int) = (i: @annotation.switch) match {
                                                     ^

然而

object Final {
   final val a = 0
   final val b = 1

   def test(i: Int) = (i: @annotation.switch) match {
      case `a` => true
      case `b` => false
   }
}

编译时没有警告，因此可能会生成更快的模式匹配表。

不得不添加final对我来说似乎纯粹是烦人的噪音。不是object决赛本身，因此也是它的成员？

4

3 回答 3

27

这在规范中明确解决，它们自动是最终的：

final 类或对象的成员也是隐式的 final，因此final修饰符通常对它们也是多余的。但是请注意，常量值定义（第 4.1 节）确实需要显式final修饰符，即使它们是在最终类或对象中定义的。

Your final-less example compiles without errors (or warnings) with 2.10-M7, so I'd assume that there's a problem with the @switch checking in earlier versions, and that the members are in fact final.

Update: Actually this is more curious than I expected—if we compile the following with either 2.9.2 or 2.10-M7:

object NonFinal {
  val a = 0
}

object Final {
  final val a = 0
}

javap does show a difference:

public final class NonFinal$ implements scala.ScalaObject {
  public static final NonFinal$ MODULE$;
  public static {};
  public int a();
}

public final class Final$ implements scala.ScalaObject {
  public static final Final$ MODULE$;
  public static {};
  public final int a();
}

You see the same thing even if the right-hand side of the value definitions isn't a constant expression.

So I'll leave my answer, but it's not conclusive.

于 2012-09-06T22:35:53.807 回答
23

You're not asking "why aren't they final", you're asking "why aren't they inlined." It just happens that final is how you cue the compiler that you want them inlined.

The reason they are not automatically inlined is separate compilation.

object A { final val x = 55 }
object B { def f = A.x }

When you compile this, B.f returns 55, literally:

public int f();
  0: bipush        55
  2: ireturn

That means if you recompile A, B will be oblivious to the change. If x is not marked final in A, B.f looks like this instead:

  0: getstatic     #19                 // Field A$.MODULE$:LA$;
  3: invokevirtual #22                 // Method A$.x:()I
  6: ireturn

Also, to correct one of the other answers, final does not mean immutable in scala.

于 2012-09-11T05:52:57.070 回答
3

To address the central question about final on an object, I think this clause from the spec is more relevant:

A constant value definition is of the form final val x = e where e is a constant expression (§6.24). The final modifier must be present and no type annotation may be given. References to the constant value x are themselves treated as constant expressions; in the generated code they are replaced by the definition’s right-hand side e.

Of significance:

  • No type annotation may be given
  • The expression e is used in the generated code (by my reading, as the original unevaluated constant expression)

It sounds to me like the compiler is required by the spec to use these more like macro replacements rather than values that are evaluated in place at compile time, which could have impacts on how the resulting code runs.

I think it is particularly interesting that no type annotation may be given.

This, I think points to our ultimate answer, though I cannot come up with an example that shows the runtime difference for these requirements. In fact, in my 2.9.2 interpreter, I don't even get the enforcement of the first rule.

于 2012-09-07T18:15:56.443 回答