Programming in Scala Gist 13
Published in
6 min readMay 30, 2016
--
These are the key points from the Programming in Scala, Second Edition by Martin Odersky, Lex Spoon, Bill Venners. I wanted to make note of some key points. They may seem broken and not make much sense, if you have not read the book. This is for personal reference. Feel free to correct me if I have interpreted anything wrong in this post.
Chapter 13 — Packages and Imports
It is important to minimize coupling while working on large projects and one way to minimize coupling is to write in a modular style.
13.1 Putting code in packages
Scala packages also use reverse-domain-name convention for Scala packages. Two ways to place code in Scala’s named packages.
- Package clause at the top of the file — the contents of an entire file will be placed into the package
- Packaging — the definitions that go into the package are placed within {}
13.2 Concise access to related code
- As per package hierarchy the code placed in the same package is related in some way to each other.
- Scala allows short, unqualified names when accessing code that is in the same package
- A class can be accessed from within its own package without needing a prefix
- A package itself can be accessed from within its own package without needing a prefix
- When using the curly-braces packaging syntax, all names accessible in scopes outside the packaging are also available inside it. This kind of accessing is only available if the packages are explicitly nested in the packaging.
- When the packages are one per file, then the only names available will be the ones defined in the current package.
- chained package clauses: The code that shifts completely right can be used with multiple package clauses without braces.
- Scala provides a package named _root_ that is outside any package a user can write. Every top-level package is a member of _root_
13.3 Imports
In Scala, packages and their members can be imported using import clauses which enables item access with a simple name like File instead of java.io.File
- Scala imports can appear anywhere, not just at the beginning of a compilation unit.
- Scala imports are flexible to import other packages within them as well and not just non-package members
- Scala import can rename or hide members with an import selector clause enclosed in braces.
import Fruits.{Apple, Orange} // Import just Apple and Orange from Fruitsimport Fruits.{Apple => McIntosh, Orange} // Import Apple and Orange and rename Apple as McIntosh and can be accessed with either Fruits.Apple or McIntosh.
- A simple name x. This includes x in the set of imported names
- A renaming clause x=>y. This makes the member named x visible under the name y.
- A hiding clause x=>_ This excludes x from the set of imported names
- A catch-all ‘_’. Import all members except those that are hidden using the hiding clause. If a catch-all is given, it muse come last in the list of import selectors
- import p._ → import p.{_}
- import.p.n → import p.{n}
//Import SQL date as SDate to enable import of other Date class(Java Date) as Date
> import java.sql.{Date=>SDate}//Import java.sql pkg as S, to write things like S.Date
> import java.{sql=>s}// Import all members of Fruit, similar to Fruits._
> import Fruits.{_}// Import all members of fruit and rename Apple
> import Fruits.{Apple=>McIntosh,_}//Import all members of fruit except pear
> import Fruits.{Pear=>_,_}
13.4 Implicit imports
Scala adds some imports implicitly to every program.
13.5 Access modifiers
Access modifiers such as private and protected restrict accesses to the members to certain regions of code.
Private members
- A member labeled private is visible only inside the class or object that contains the member definition. In Scala, this rule applies also for inner classes.
class Outer{
class Inner{
private def f() { println("f") }
class InnerMost {
f() // OK
}
}
(new Inner).f() //error: f is not accessible
}- In the example above, (new Inner).f() is illegal because f is called outside of the class where as class Innermost is within the class. In Java, both are permitted because it lets an outer class access private member of its inner classes.
Protected members
- In Scala, a protected member is only accessible from subclass of the class in which the member is defined.
Public members
- public is the default access modifier for all members. Such members can be accessed from anywhere
Scope of protection
- Access modifiers in Scala can be augmented with qualifiers. Qualified access modifiers give you very fine-grained control over visibility.
- A modifier of the form private[X] or protected[X} means that access is private or protected “up to” X, where X designates some enclosing package, class or singleton object.
- class Navigator with access modifier private[bobsrockets] enables visibility to all classes and objects that are contained in package bobsrockets.
- A modifier protected[X] in a class C allows access to the labeled definition in all subclasses of C and also within the enclosing package, class or object X.
- Access qualifiers allows you to define things that are visible in several sub-packages of the project but remain hidden from clients external to the project.
- object-private: A definition labeled private[this] is accessible only from within the same object that contains the definition.
- Making a member private[this] is a guarantee that it will not be seen from other objects of the same class.
Visibility and companion objects
- Scala’s access rules privilege companion objects and classes when it comes to private or protected accesses.
- A class shares all its access rights with its companion class, just as a class can access all private members of its companion object
13.6 Package objects
- Package object: Each package is allowed to have one package object. Any definition places in a package object are considered members of the package itself.
- Package objects are defined as “package object <name> { … }”
- Package objects are frequently used to hold package-wide type aliases and implicit conversions.
- They are compiled to class files named package.class that are located in the directory of the package that they augment.
- A preferred convention for package object x is to place them in a file called package.scala in a directory called x
Conclusion
Packages are the basic constructs for dividing a program into packages. Packages enabled modularity to make it easy to work with large bodies of code without trampling each other.
Previous:
Next:
Coming Soon …
