Файл: Programming_in_Scala,_2nd_edition.pdf

One final trick is important to know. Sometimes, you end up coding in a heavily crowded scope where package names are hiding each other. In Listing 13.6, the scope of class MissionControl includes three separate packages named launch! There’s one launch in bobsrockets.navigation, one in bobsrockets, and one at the top level. How would you reference each of Booster1, Booster2, and Booster3?

Accessing the first one is easiest. A reference to launch by itself will get you to package bobsrockets.navigation.launch, because that is the launch package defined in the closest enclosing scope. Thus, you can refer to the first booster class as simply launch.Booster1. Referring to the second one also is not tricky. You can write bobrockets.launch.Booster2 and be clear about which one you are referencing. That leaves the question of the third booster class, however. How can you access Booster3, considering that a nested launch package shadows the top-level one?

To help in this situation, Scala provides a package named _root_ that is outside any package a user can write. Put another way, every top-level package you can write is treated as a member of package _root_. For example, both launch and bobsrockets of Listing 13.6 are members of package _root_. As a result, _root_.launch gives you the top-level launch package, and _root_.launch.Booster3 designates the outermost booster class.

13.3 Imports

In Scala, packages and their members can be imported using import clauses. Imported items can then be accessed by a simple name like File, as opposed to requiring a qualified name like java.io.File. For example, consider the code shown in Listing 13.7.

An import clause makes members of a package or object available by their names alone without needing to prefix them by the package or object name. Here are some simple examples:

//easy access to Fruit import bobsdelights.Fruit

//easy access to all members of bobsdelights import bobsdelights._

//easy access to all members of Fruits import bobsdelights.Fruits._

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index

package bobsdelights

abstract class Fruit( val name: String, val color: String

)

object Fruits {

object Apple extends Fruit("apple", "red") object Orange extends Fruit("orange", "orange") object Pear extends Fruit("pear", "yellowish") val menu = List(Apple, Orange, Pear)

}

Listing 13.7 · Bob’s delightful fruits, ready for import.

The first of these corresponds to Java’s single type import, the second to Java’s on-demand import. The only difference is that Scala’s on-demand imports are written with a trailing underscore (_) instead of an asterisk (*) (after all, * is a valid identifier in Scala!). The third import clause above corresponds to Java’s import of static class fields.

These three imports give you a taste of what imports can do, but Scala imports are actually much more general. For one, imports in Scala can appear anywhere, not just at the beginning of a compilation unit. Also, they can refer to arbitrary values. For instance, the import shown in Listing 13.8 is possible:

def showFruit(fruit: Fruit) { import fruit._

println(name +"s are "+ color)

}

Listing 13.8 · Importing the members of a regular (not singleton) object.

Method showFruit imports all members of its parameter fruit, which is of type Fruit. The subsequent println statement can refer to name and color directly. These two references are equivalent to fruit.name and fruit.color. This syntax is particularly useful when you use objects as modules, which will be described in Chapter 29.

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index

Scala’s flexible imports

Scala’s import clauses are quite a bit more flexible than Java’s. There are three principal differences. In Scala, imports:

•may appear anywhere

•may refer to objects (singleton or regular) in addition to packages

•let you rename and hide some of the imported members

Another way Scala’s imports are flexible is that they can import packages themselves, not just their non-package members. This is only natural if you think of nested packages being contained in their surrounding package. For example, in Listing 13.9, the package java.util.regex is imported. This makes regex usable as a simple name. To access the Pattern singleton object from the java.util.regex package, you can just say, regex.Pattern, as shown in Listing 13.9:

import java.util.regex

class AStarB {

// Accesses java.util.regex.Pattern val pat = regex.Pattern.compile("a*b")

}

Listing 13.9 · Importing a package name.

Imports in Scala can also rename or hide members. This is done with an import selector clause enclosed in braces, which follows the object from which members are imported. Here are some examples:

import Fruits.{Apple, Orange}

This imports just members Apple and Orange from object Fruits.

import Fruits.{Apple => McIntosh, Orange}

This imports the two members Apple and Orange from object Fruits. However, the Apple object is renamed to McIntosh. So this object can be

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index

accessed with either Fruits.Apple or McIntosh. A renaming clause is always of the form “<original-name> => <new-name>”.

import java.sql.{Date => SDate}

This imports the SQL date class as SDate, so that you can simultaneously import the normal Java date class as simply Date.

import java.{sql => S}

This imports the java.sql package as S, so that you can write things like S.Date.

import Fruits.{_}

This imports all members from object Fruits. It means the same thing as import Fruits._.

import Fruits.{Apple => McIntosh, _}

This imports all members from object Fruits but renames Apple to

McIntosh.

import Fruits.{Pear => _, _}

This imports all members of Fruits except Pear. A clause of the form “<original-name> => _” excludes <original-name> from the names that are imported. In a sense, renaming something to ‘_’ means hiding it altogether. This is useful to avoid ambiguities. Say you have two packages, Fruits and Notebooks, which both define a class Apple. If you want to get just the notebook named Apple, and not the fruit, you could still use two imports on demand like this:

import Notebooks._

import Fruits.{Apple => _, _}

This would import all Notebooks and all Fruits except for Apple.

These examples demonstrate the great flexibility Scala offers when it comes to importing members selectively and possibly under different names. In summary, an import selector can consist of the following:

• A simple name x. This includes x in the set of imported names.

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index

•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 ‘_’. This imports all members except those members mentioned in a preceding clause. If a catch-all is given, it must come last in the list of import selectors.

The simpler import clauses shown at the beginning of this section can be seen as special abbreviations of import clauses with a selector clause. For example, “import p._” is equivalent to “import p.{_}” and “import p.n” is equivalent to “import p.{n}”.

13.4 Implicit imports

Scala adds some imports implicitly to every program. In essence, it is as if the following three import clauses had been added to the top of every source file with extension “.scala”:

import java.lang._ // everything in the java.lang package import scala._ // everything in the scala package import Predef._ // everything in the Predef object

The java.lang package contains standard Java classes. It is always implicitly imported on the JVM implementation of Scala. The .NET implementation would import package system instead, which is the .NET analogue of java.lang. Because java.lang is imported implicitly, you can write

Thread instead of java.lang.Thread, for instance.

As you have no doubt realized by now, the scala package contains the standard Scala library, with many common classes and objects. Because scala is imported implicitly, you can write List instead of scala.List, for instance.

The Predef object contains many definitions of types, methods, and implicit conversions that are commonly used on Scala programs. For example, because Predef is imported implicitly, you can write assert instead of

Predef.assert.

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index

The three import clauses above are treated a bit specially in that later imports overshadow earlier ones. For instance, the StringBuilder class is defined both in package scala and, from Java version 1.5 on, also in package java.lang. Because the scala import overshadows the java.lang import, the simple name StringBuilder will refer to scala.StringBuilder, not java.lang.StringBuilder.

13.5 Access modifiers

Members of packages, classes, or objects can be labeled with the access modifiers private and protected. These modifiers restrict accesses to the members to certain regions of code. Scala’s treatment of access modifiers roughly follows Java’s but there are some important differences which are explained in this section.

Private members

Private members are treated similarly to Java. 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. This treatment is more consistent, but differs from Java. Consider the example shown in Listing 13.10:

class Outer { class Inner {

private def f() { println("f") } class InnerMost {

f() // OK

}

}

(new Inner).f() // error: f is not accessible

}

Listing 13.10 · How private access differs in Scala and Java.

In Scala, the access (new Inner).f() is illegal because f is declared private in Inner and the access is not from within class Inner. By contrast, the first access to f in class InnerMost is OK, because that access

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index

is contained in the body of class Inner. Java would permit both accesses because it lets an outer class access private members of its inner classes.

Protected members

Access to protected members is also a bit more restrictive than in Java. In Scala, a protected member is only accessible from subclasses of the class in which the member is defined. In Java such accesses are also possible from other classes in the same package. In Scala, there is another way to achieve this effect, as described below, so protected is free to be left as is. The example shown in Listing 13.11 illustrates protected accesses:

package p { class Super {

protected def f() { println("f") }

}

class Sub extends Super { f()

}

class Other {

(new Super).f() // error: f is not accessible

}

}

Listing 13.11 · How protected access differs in Scala and Java.

In Listing 13.11, the access to f in class Sub is OK because f is declared protected in Super and Sub is a subclass of Super. By contrast the access to f in Other is not permitted, because Other does not inherit from Super. In Java, the latter access would be still permitted because Other is in the same package as Sub.

Public members

Every member not labeled private or protected is public. There is no explicit modifier for public members. Such members can be accessed from anywhere.

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index

package bobsrockets

package navigation { private[bobsrockets] class Navigator {

protected[navigation] def useStarChart() {} class LegOfJourney {

private[Navigator] val distance = 100

}

private[this] var speed = 200

}

}

package launch { import navigation._ object Vehicle {

private[launch] val guide = new Navigator

}

}

Listing 13.12 · Flexible scope of protection with access qualifiers.

Scope of protection

Access modifiers in Scala can be augmented with qualifiers. 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.

Qualified access modifiers give you very fine-grained control over visibility. In particular they enable you to express Java’s accessibility notions such as package private, package protected, or private up to outermost class, which are not directly expressible with simple modifiers in Scala. But they also let you express accessibility rules that cannot be expressed in Java. Listing 13.12 presents an example with many access qualifiers being used. In this listing, class Navigator is labeled private[bobsrockets]. This means that this class is visible in all classes and objects that are contained in package bobsrockets. In particular, the access to Navigator in object Vehicle is permitted, because Vehicle is contained in package launch, which is contained in bobsrockets. On the other hand, all code outside the package bobsrockets cannot access class Navigator.

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index