val or object for immutable, final singleton object

Question

Which solution should be generally preferred, considering that the change is source compatible?

This

object Foo {
  val Bar = new Baz(42, "The answer", true)
}

or this?

object Foo {
  object Bar extends Baz(42, "The answer", true)
}

Domineca

I would say first one is better if you want to modularize your API differently in the future without too much modification... but since the change is source compatible you can keep the second until needed. – Wyler

Possible duplicate of val and object inside a scala class? – Barrington

Answer 1

The functional difference between the two constructs is that object Bar is only created when it is needed, while val Bar is created as soon as object Foo is used. As a practical matter, this means you should use the object (or lazy val) if the right-hand side is expensive and won't always be needed. Otherwise, val is probably simpler.

Also, note that if the class Baz is final, you won't be able to use the object style since you can't extend Baz (though you can still use lazy val if you want to defer creation until it's needed).

Recidivism

Sorry, I wasn't clear enough. I meant with final that the variable Bar won't be reassigned. Isn't the bytecode for object slightly simpler than the code for lazy val? – Domineca

@Domineca - Yes, lazy val is more complex code (and threadsafe). And I edited my answer to make it clearer what I meant regarding final. – Recidivism

@Domineca - Doesn't look like it to me; the object initializer code doesn't seem to be thread-aware. You can check the bytecode. – Recidivism

Afaik it uses the same strategy like singleton enums in Java where the VM guarantees thread-safety, not the bytecode. – Domineca

@Domineca - Could be. This isn't something I'm terribly familiar with. – Recidivism

Answer 2

I say the first since in the second, you are creating a new class but don't add any information (no overriding of methods, values or new ones).

Whereas