why aren't module classes final?

[Eugene Burmako]

Last login: Mon Mar 18 13:41:43 on ttys001
s15:27 ~$ 210x
15:27 ~/Projects/210x (2.10.x)$ scala
Welcome to Scala version 2.10.2-20130312-191623-b7b4f87732 (Java
HotSpot(TM) 64-Bit Server VM, Java 1.6.0_43).
Type in expressions to have them evaluated.
Type :help for more information.

scala> object D
defined module D

scala> val mc = typeOf[D.type].typeSymbol
mc: reflect.runtime.universe.Symbol = object D

scala> mc.isModuleClass
res0: Boolean = true

scala> mc.isFinal
res1: Boolean = false

[Simon Ochsenreither]

Maybe it causes issues when overriding (-Yoverride-objects)?

[Paul Phillips]

objects and lazy vals should be seen as the same thing for which, through accidents of history, different feature sets exist. You can override lazy vals; you should be able to override objects.

[Peter Empen]

final object D

val mc = typeOf[D.type].typeSymbol

mc.isFinal
res1: Boolean = true

"final is redundant for object definitions..." (5.2 Modifiers in Spec)

Ups, is it redundant or not? Is there a difference in the byte code, too?

[Paul Phillips]

On Mon, Mar 18, 2013 at 1:32 PM, Peter Empen <peter...@arcor.de> wrote:

"final is redundant for object definitions..." (5.2 Modifiers in Spec)

The specification is not always a reliable source of information.

Ups, is it redundant or not? Is there a difference in the byte code, too?

It is redundant at the scala language level at present, because we haven't yet unified objects and lazy vals. There is a difference in the bytecode; the module class is marked final if you marked it final, and not if you didn't.

[Peter Empen]

There is a difference in the bytecode; the module class is marked final if you marked it final, and not if you didn't.

I'd expect the compiler to always mark module classes final.

[Paul Phillips]

On Tue, Mar 19, 2013 at 1:29 AM, Peter Empen <peter...@arcor.de> wrote:

I'd expect the compiler to always mark module classes final.

Wasn't this entire thread about why it doesn't?