Open In App
Related Articles

Chained Package Clauses in Scala

Improve
Improve
Improve
Like Article
Like
Save Article
Save
Report issue
Report
Chained packages are way resolving the visibility of members of a package members. This was introduced in Scala 2.8 as described by Martin Odersky Suppose we have a code like below. Let’s break the code and understand what happens here.
package x.z
object a {
  b  //object b
}
object b{
  a  //object a
}
or we could write the above code as below
// but this is not a good and short way of writing package clauses
// let's just stick to the first style.
package x{
   package z{
      object a {
      }
      object b{
      }
  }
}
Here objects a and b are defined in a directory z which is in a directory x. Visibility for package z are members a and b, and not of members x. And we can also write these objects as in different scala files as below.
// a.scala
package x.z
object a {
  b //object b still visible
}
// b.scala
package x.z
object b{
  a // object a still visible
}
// files would created like this
+x
  +z
    +a.scala
    +b.scala
 
Why the chaining of package clauses were introduced?
To change the meaning of the package clause and to shorten the package clause while importing files, so that we should not have to write the whole package name when working on bigger projects which would contain multiple different nested sub packages. Let’s just understand it with an eg’s whose directory structure is something like this:-
+company
      +ceo
         +Ceo.scala
         +directors
               +Director.scala
               +managers
                     +hrManager.scala
                     +techManager.scala
                     +employees
                             +employee.scala
// employee.scala
package company.ceo.directors.managers

package employees{
    object employee extends Enumeration{
      val employee1= Value
      val employee2= Value
      val employee3= Value
    }
}
// hrManager.scala
package company.ceo.directors.managers

//short form to import employee3
import employees.employee.employee3  
object hrManager extends Enumeration{
  val hR1, hR2 = Value
  val hrAssociate= employee3
}
// techManager.scala
package company.ceo.directors.managers

// short form to import employee1
import employees.employee.employee1  
object techManager extends Enumeration{
val tmanager= Value
val techAssociate=employee1

// directly specifying employee2
val Assistant= employees.employee.employee2  
val x=Director
}
So in the above files instead of writing the whole package clause as below.
import company.ceo.directors.managers.employees.employee.employee1 //techManager.scala import company.ceo.directors.managers.employees.employee.employee2 //techManager.scala import company.ceo.directors.managers.employees.employee.employee3 //hrManager.scala
we wrote the directory name which is in the current/same base as with the file in which are importing in
+hrManager.scala        //file
+techManager.scala      //file
+employees              //directory
These 3 files are in the same scope therefore we see hrManager or techManager or employees in the scope and hence we used them & none of the other can be seen in the scope. thus for importing multiple files we can include a ‘_’ at the end of dot to import all the members without specifying all of them. From the first example object a & object b are in the same level of scope hence therefore we could see and use them.

Last Updated : 06 May, 2019
Like Article
Save Article
Previous
Next
Share your thoughts in the comments
Similar Reads