Reputation: 11512
I have seen in a few libraries, Spray for example, dual package specifications like this:
package cc.spray
package http
// code
Is this just eye candy for package cc.spray.http, or is there a functional benefit to breaking the two apart like this?
Upvotes: 7
Views: 274
Reputation: 11237
let's not forget one nice win gained from this approach
// Foo.scala
package cc.spray
package http
class Foo {
...
}
// Bar.Scala
package cc.spray
package bar
import http._ // concise imports relative to cc.spray
class Bar {
...
}
Upvotes: 1
Reputation: 3982
Like a lot of other things, this was introduced with Scala 2.8: the other answers give you the "what" (exposing multiple package scopes to the current context) and the official Scala doc has a lot more detail, along with a detailed rationale for the feature.
Upvotes: 0
Reputation: 297165
That is equivalent to this:
package cc.spray.http
import cc.spray._
// implicitly, import cc.spray.http._
That is, every member of package cc.spray
and of package cc.spray.http
are visible. On the other hand, members of the package cc
are not visible.
This way one can safely use names such as java
in their package hierarchy without causing trouble, and, at the same time, easily make visible the package scopes one wants to be visible.
Upvotes: 8
Reputation: 24032
The separate package statements puts both cc.spray
and cc.spray.http
in scope.
Upvotes: 3