Why people define class, trait, object inside another object in Scala?

Question

Ok, I'll explain why I ask this question. I begin to read Lift 2.2 source code these days. It's good if you happened to read lift source code before.

In Lift, I found that, define inner class and inner trait are very heavily used.

object Menu has 2 inner traits and 4 inner classes. object Loc has 18 inner classes, 5 inner traits, 7 inner objects.

There're tons of codes write like this. I wanna to know why the author write like this.

• Is it because it's the author's personal taste or a powerful use of language feature?
• Is there any trade-off for this kind of usage?

Sanity

Answer 1

Before 2.8, you had to choose between packages and objects. The problem with packages is that they cannot contain methods or vals on their own. So you have to put all those inside another object, which can get awkward. Observe:

object Encrypt {
  private val magicConstant = 0x12345678
  def encryptInt(i: Int) = i ^ magicConstant
  class EncryptIterator(ii: Iterator[Int]) extends Iterator[Int] {
    def hasNext = ii.hasNext
    def next = encryptInt(ii.next)
  }
}

Now you can import Encrypt._ and gain access to the method encryptInt as well as the class EncryptIterator. Handy!

In contrast,

package encrypt {
  object Encrypt {
    private[encrypt] val magicConstant = 0x12345678
    def encryptInt(i: Int) = i ^ magicConstant
  }
  class EncryptIterator(ii: Iterator[Int]) extends Iterator[Int] {
    def hasNext = ii.hasNext
    def next = Encrypt.encryptInt(ii.next)
  }
}

It's not a huge difference, but it makes the user import both encrypt._ and encrypt.Encrypt._ or have to keep writing Encrypt.encryptInt over and over. Why not just use an object instead, as in the first pattern? (There's really no performance penalty, since nested classes aren't actually Java inner classes under the hood; they're just regular classes as far as the JVM knows, but with fancy names that tell you that they're nested.)

In 2.8, you can have your cake and eat it too: call the thing a package object, and the compiler will rewrite the code for you so it actually looks like the second example under the hood (except the object Encrypt is actually called package internally), but behaves like the first example in terms of namespace--the vals and defs are right there without needing an extra import.

Thus, projects that were started pre-2.8 often use objects to enclose lots of stuff as if they were a package. Post-2.8, one of the main motivations has been removed. (But just to be clear, using an object still doesn't hurt; it's more that it's conceptually misleading than that it has a negative impact on performance or whatnot.)

(P.S. Please, please don't try to actually encrypt anything that way except as an example or a joke!)

Unit

Is nested class in a object exactly the same as Java's static inner class? If I put 100 inner class, or 100 inner object in a companion object, how will the compiler treat them? Absolutely no performance penalty? – Sanity

A nested class Bar inside a class or object Foo is implemented as not an inner class but an outer class with the name Foo$Bar, and only if it actually needs to use its parent class will it have a (sort-of-hidden) field that points to the parent. The compiler rather than the JVM enforces that you use this properly, and in the case of an object, it knows there's only one so it doesn't need to bother storing that field. – Unit

Answer 2

Putting classes, traits and objects in an object is sometimes required when you want to use abstract type variables, see e.g. http://programming-scala.labs.oreilly.com/ch12.html#_parameterized_types_vs_abstract_types

Goodish

Answer 3

It can be both. Among other things, an instance of an inner class/trait has access to the variables of its parent. Inner classes have to be created with a parent instance, which is an instance of the outer type.

In other cases, it's probably just a way of grouping closely related things, as in your object example. Note that the trait LocParam is sealed, which means that all subclasses have to be in the same compile unit/file.

Nympho

Use object to group related things doesn't feel good to me, I think it's the package's usage. – Sanity

@Zwcat: There's a lot of truth to what you say. As a matter of convenience, however, it may less hassle to have all of these little things in one file rather than in so many files in the same directory. Using the sealed keyword makes it necessary to put them in the same file and wrapping them in a containing object will seem less messy. – Nympho

Answer 4

sblundy has a decent answer. One thing to add is that only with Scala 2.8 do you have package objects which let you group similar things in a package namespace without making a completely separate object. For that reason I will be updating my Lift Modules proposal to use a package object instead of a simple object.

Juncture