Comments on Programming Scala

Comment on 'Visibility Rules'

2009-08-04T21:44:06-07:00

Visibility Rules

When you compile this file with scalac, you get the following output. (The file name before the N: line numbers have been removed from the output to better fit the space.)

in: def equalFields(other: ProtectedClass1) = (protectedField1 == other.protectedField1) && (protectedField1 == other.protectedField1) && (nested == other.nested) there is a typing error should be def equalFields(other: ProtectedClass1) = (protectedField1 == other.protectedField1) && (protectedField2 == other.protectedField2) && (nested == other.nested)
— shalom (2009-08-04 21:44:06)

Comment on 'Visibility Rules'

2009-08-02T05:18:35-07:00

Visibility Rules

Let’s begin by considering the only differences in behavior between scoped private and scoped public, how they behave under inheritance when members have these scopes.

Let’s begin by considering the only differences in behavior between scoped private and scoped public

Probably meant

Let’s begin by considering the only differences in behavior between scoped private and scoped protected
— maddalab (2009-08-02 05:18:35)

Comment on 'Visibility Rules'

2009-08-02T04:41:25-07:00

Visibility Rules

Table 5.1, “Visibility Scopes.” summarizes the visibility scopes.

wouldn't this suffice, in the note
class Restricted[A] private (name: String) {…}
especially since you have not yet mentioned variance and type parameters.
— maddalab (2009-08-02 04:41:25)

Comment on 'Constructors in Scala'

2009-08-01T17:30:31-07:00

Constructors in Scala

The primary constructor for RadioButtonWithCallbacks takes three parameters: an on state (true or false), a label, and a list of callbacks. It passes the label and list of callbacks to its parent class, ButtonWithCallbacks. The on parameter is declared as a var, so it is mutable. on is also the one constructor parameter unique to a radio button, so it is kept as an attribute of RadioButtonWithCallbacks.

class RadioButtonWithCallbacks(
  var on: Boolean, label: String, clickedCallbacks: List[() => Unit])
      extends ButtonWithCallbacks(label, clickedCallbacks)
What happened the the val keywords before label and clickedCallbacks. I figured out why they are not used, however they reason deserves a mention — maddalab (2009-08-01 17:30:31)

Comment on 'Constructors in Scala'

2009-07-14T10:32:51-07:00

Constructors in Scala

For consistency with its parent class, RadioButtonWithCallbacks also declares two auxiliary constructors. Note that they must invoke a preceding constructor in RadioButtonWithCallbacks, as before. They can’t invoke a ButtonWithCallbacks constructor directly. Declaring all these constructors in each class could get tedious after a while, but we explored techniques in Chapter 4, Traits that can eliminate repetition.

This presumably also means that a given subclass may only invoke one of the parent class's constructors. Compare that to, for instance, Java exception hierarchies, where there tends to be a parallel hierarchy of constructors.
— diathesis (2009-07-14 10:32:51)

Comment on 'Parent Classes'

2009-07-14T10:22:16-07:00

Parent Classes

Scala supports single inheritance, not multiple inheritance. A child (or derived) class can have one and only one parent (or base) class. The sole exception is the root of the Scala class hierarchy, Any, which has no parent.

I was just wondering why the 'Any' class was allowed to have more than one parent class, 'til I read these comments.
— diathesis (2009-07-14 10:22:16)

Comment on 'Visibility Rules'

2009-07-12T21:40:08-07:00

Visibility Rules

Table 5.1. Visibility Scopes.

Name	Keyword	Description
public	none	Public members and types are visible everywhere, across all boundaries.
protected	`protected`	Protected members are visible to the defining type, to derived types, and to nested types. Protected types are visible only within the same package and subpackages.
private	`private`	Private members are visible only within the defining type and nested types. Private types are visible only within the same package.
scoped protected	`protected[scope]`	Visibility is limited to `scope`, which can be a package, type, or `this` (meaning the same instance, when applied to members, or the enclosing package, when applied to types). See the text below for details.
scoped private	`private[scope]`	Synonymous with scoped protected visibility, except under inheritance (discussed below).

@Alexander: no, that's not possible. @Mario: true. thanks. will fix.
— deanwampler (2009-07-12 21:40:08)

Comment on 'Constructors in Scala'

2009-07-12T21:38:17-07:00

Constructors in Scala

The primary constructor in a derived class must invoke one of the parent class constructors, either the primary constructor or an auxiliary constructor. In the following example, a class derived from ButtonWithCallbacks, called RadioButtonWithCallbacks, invokes the primary ButtonWithCallbacks constructor. “Radio” buttons can be either on or off.

Limited by the print format.
— deanwampler (2009-07-12 21:38:17)

Comment on 'Constructors in Scala'

2009-07-12T21:29:22-07:00

Constructors in Scala

If a parameter has the var keyword, a public writer method is also generated with the parameter’s name as a prefix, followed by _=. For example, if label were declared as a var, the writer method would be named label_= and it would take a single argument of type String.

True. Will clarify.
— deanwampler (2009-07-12 21:29:22)

Comment on 'Constructors in Scala'

2009-07-12T21:29:12-07:00

Constructors in Scala

ButtonWithCallbacks defines three constructors. The primary constructor, which is the body of the entire class, has a parameter list that takes a label string and a list of callback functions. Because each parameter is declared as a val, the compiler generates a private field corresponding to each parameter (a different internal name is used), along with a public reader method that has the same name as the parameter. “Private” and “public” have the same meaning here as in most object-oriented languages. We’ll discuss the various visibility rules and the keywords that control them in the section called “Visibility Rules” below.

We'll describe this later.
— deanwampler (2009-07-12 21:29:12)

Comment on 'Parent Classes'

2009-07-12T21:17:32-07:00

Parent Classes

As in Java, the keyword extends indicates the parent class, in this case BulkReader. In Scala, extends is also used when a class inherits a trait as its parent (even when it mixes in other traits using the with keyword). Also, extends is used when one trait is the child of another trait or class. Yes, traits can inherit classes.

Thanks. will clarify.
— deanwampler (2009-07-12 21:17:32)

Comment on 'Parent Classes'

2009-07-12T21:16:28-07:00

Parent Classes

Thanks. will consider this rewording.
— deanwampler (2009-07-12 21:16:28)

Comment on 'Constructors in Scala'

2009-07-10T07:46:23-07:00

Constructors in Scala

It should be specified what happens when you don't use neither val nor val.
— bieffe (2009-07-10 07:46:23)

Comment on 'Visibility Rules'

2009-07-03T14:33:45-07:00

Visibility Rules

Scala’s visibility rules are similar to Java’s, but tend to be both more consistently applied and more flexible. For example, in Java, if an inner class has a private member, the enclosing class can see it. In Scala, the enclosing class can’t see a private member, but Scala provides another way to declare it visible to the enclosing class.

Thanks. Added this to the table below.
— deanwampler (2009-07-03 14:33:45)

Comment on 'Visibility Rules'

2009-06-28T04:03:03-07:00

Visibility Rules

Table 5.1. Visibility Scopes.

Name	Keyword	Description
public	none	Public members and types are visible everywhere, across all boundaries.
protected	`protected`	Protected members are visible to the defining type, to derived types, and to nested types. Protected types are visible only within the same package and subpackages.
private	`private`	Private members are visible only within the defining type and nested types. Private types are visible only within the same package.
scoped protected	`protected[scope]`	Visibility is limited to `scope`, which can be a package, type, or `this` (meaning the same instance, when applied to members, or the enclosing package, when applied to types). See the text below for details.
scoped private	`private[scope]`	Synonymous with scoped protected visibility, except under inheritance (discussed below).

Protected types are also visible within the sub packages.
— magle (2009-06-28 04:03:03)

Comment on 'Constructors in Scala'

2009-06-25T16:32:57-07:00

Constructors in Scala

You can also see, that you always firstly have to call the primary or another auxiliary constructor when defining an auxiliary constructor.
— magle (2009-06-25 16:32:57)

Comment on 'Parent Classes'

2009-06-25T16:03:44-07:00

Parent Classes

Keyword extends does not explicitly / always indicate the parent class. It is also used to mix in a trait (in case a class implicitly / only inherits from Any)
— magle (2009-06-25 16:03:44)

Comment on 'Constructors in Scala'

2009-06-21T08:33:11-07:00

Constructors in Scala

In order to avoid infinite recursion, Scala requires each auxiliary constructor to invoke another constructor defined before it [ScalaSpec2009]. The constructor invoked may be either another auxiliary constructor or the primary constructor, and it must be the first statement in the auxiliary constructor’s body. Additional processing can occur after this call, such as the warning message printed in our example.

another constructors <-
— robcd (2009-06-21 08:33:11)

Comment on 'Visibility Rules'

2009-06-14T14:38:10-07:00

Visibility Rules

Let’s explore these visibility options in more detail. To keep things simple, we’ll use fields for member examples. Method and type declarations behave the same way.

The note below is good! The 'non apologizing' for the missing but useful feature of being able to set visibility for packages is IMHo much better than the varieties of "we didn't need that feature often" often found in books about various programming languages.
— battisti (2009-06-14 14:38:10)

Comment on 'Visibility Rules'

2009-06-14T14:33:53-07:00

Visibility Rules

Table 5.1. Visibility Scopes.

Name	Keyword	Description
public	none	Public members and types are visible everywhere, across all boundaries.
protected	`protected`	Protected members are visible to the defining type, to derived types, and to nested types. Protected types are visible only within the same package and subpackages.
private	`private`	Private members are visible only within the defining type and nested types. Private types are visible only within the same package.
scoped protected	`protected[scope]`	Visibility is limited to `scope`, which can be a package, type, or `this` (meaning the same instance, when applied to members, or the enclosing package, when applied to types). See the text below for details.
scoped private	`private[scope]`	Synonymous with scoped protected visibility, except under inheritance (discussed below).

"Private members are visible only within the defining type. Private types are visible only within the same package." Is it possible to define a single type across multiple packages?
— battisti (2009-06-14 14:33:53)

Comment on 'Visibility Rules'

2009-06-14T14:31:46-07:00

Visibility Rules

You could also mention here, that an inner class can access private members of it's outer/enclosing class.
— battisti (2009-06-14 14:31:46)

Comment on 'Constructors in Scala'

2009-06-14T14:25:19-07:00

Constructors in Scala

You should drive the point, that only the primary constructor is able (and has to) call the superclasses constructor, more clearly. Maybe even directly at the beginning of the "Calling Parent Class Constructors" section.
— battisti (2009-06-14 14:25:19)

Comment on 'Constructors in Scala'

2009-06-14T14:21:11-07:00

Constructors in Scala

Creating a dedicated example with shorter names to avoid the line breaks would be nice. It is really hard to find the call to the superclasses primary constructor after this bunch of this relatively complicated type declarations - which are not helpful at all for understanding the currently described concept. Especially if you don't show the definition of the ButtonWithCallbacks class (to allow the reader to see for him/herself which constructor of the parent class is called)
— battisti (2009-06-14 14:21:11)

Comment on 'Constructors in Scala'

2009-06-14T14:14:39-07:00

Constructors in Scala

Less Flexibility

"However, the authors find these circumstances to be rare." sounds a lot like the: "In practice type errors don't happen much." Mantra found in books about 'dynamic languages' vs. the "Static type checking is really useful." found in books about 'static languages'. The readers should know for themselves how often they found a particular language feature useful or not. You shouldn't anchor them.

Simply mentioning that Scala doesn't have this feature, hinting that use might be an indicator for violating the 'single responsibility principle' should be enough.
— battisti (2009-06-14 14:14:39)

Comment on 'Parent Classes'

2009-06-14T13:54:05-07:00

Parent Classes

Instead of "A child (or derived) class can have one and only one parent (or base) class.", "All classes have exactly one parent class." would be a more concise 'lead in' to the next sentence: "The sole exception is the root..."
— battisti (2009-06-14 13:54:05)

Comment on 'Visibility Rules'

2009-06-08T19:20:30-07:00

Visibility Rules

The only errors are when we attempt to access members scoped to scopeA from the unrelated package scopeB and when we attempt to access a member from a nested package scopeA2 that is scoped to that package.

Thanks again for the catch.
— deanwampler (2009-06-08 19:20:30)

Comment on 'Visibility Rules'

2009-06-08T19:19:47-07:00

Visibility Rules

Hence, when applied to types, private[this] is equivalent to Java’s package private visibility.

Thanks!
— deanwampler (2009-06-08 19:19:47)

Comment on 'Class and Object Basics'

2009-06-08T18:49:29-07:00

Class and Object Basics

Like Java, but unlike Ruby and Python, Scala allows overloaded methods. Two or more methods can have the same name as long as their full signatures are unique. The signature includes the type name, the list of parameters with types, and the method’s return value.

Henrik, very true. Will add text for it. Thanks. Jason, very helpful example. Thanks. We discuss the namespace issue later. I'll include links to those areas.
— deanwampler (2009-06-08 18:49:29)

Comment on 'Visibility Rules'

2009-05-20T05:30:14-07:00

Visibility Rules

s/package/private/ (below)
— retronym (2009-05-20 05:30:14)

Comment on 'Visibility Rules'

2009-05-20T05:29:53-07:00

Visibility Rules

Hence, when applied to types, private[this] is equivalent to Java’s package private visibility.

s/package/private/
— retronym (2009-05-20 05:29:53)