Comments on Programming Scala

Comment on 'Effective Design of Traits'

2009-08-04T10:51:01-07:00

Effective Design of Traits

So, Scala handles many potential issues that arise when mixing the contributions of different traits into the set of possible states of an instance. Still, it’s important to consider how the contributions of different traits interact with each other.

How are naming conflicts with mixin composition resolved? For example, if both B1 and B2 define (and implement) a method b3? If invoked on C, which would be called? One might expect the first one encountered in the linearized hierarchy. But can C's client also choose a different one? Or will the compiler complain?
— henrigerrits (2009-08-04 10:51:01)

Comment on 'Design Patterns'

2009-08-04T10:42:59-07:00

Design Patterns

We won’t discuss all the well known patterns, such as those in [GOF1995]. A number of the GOF patterns are discussed at [ScalaWiki:Patterns], along with other patterns that are somewhat specific to Scala. Instead, we’ll discuss a few illustrative examples. We’ll start by discussing a replacement for the Visitor Pattern that uses functional idioms and implicit conversations. Then we’ll discuss a powerful way of implementing Dependency Injection in Scala using the Cake Pattern.

"implicit conversations" should be "implicit conversions"
— henrigerrits (2009-08-04 10:42:59)

Comment on 'Design Patterns'

2009-08-04T10:42:17-07:00

Design Patterns

Actually, in this case, an implicit conversation is invoked to convert the java.lang.String to a RichString, which has the foreach method. That’s an example of the pattern called pimp my library, which we saw in the section called “Implicit Conversions”.

"implicit conversation" should be "implicit conversion"
— henrigerrits (2009-08-04 10:42:17)

Comment on 'Scalable Abstractions'

2009-07-26T19:25:28-07:00

Scalable Abstractions

This example encapsulates handling of strings encoding comma-separated values (CSVs) or tab-separated values (TSVs). The encodedstring package exposes a trait EncodedString that is visible to clients. The concrete classes implementing CSVs and TSVs are declared protected[encodedstring] in the encodedstring.impl package. The trait defines two abstract val fields, one to hold the encoded string, which is protected from client access, and the other to hold the separator (e.g., a comma). Recall from Chapter 6, Advanced Object-Oriented Programming In Scala that abstract fields, like abstract types and methods, must be initialized in concrete instances. In this case, string will be defined through a concrete constructor and the separator is defined explicitly in the concrete classes, CSV and TSV.

In the code, the concrete classes implementing CSVs and TSVs are declared private[encodedstring], not protected[encodedstring] as the paragraph states.
— jrduncans (2009-07-26 19:25:28)

Comment on 'Enumerations vs. Pattern Matching'

2009-07-12T22:13:32-07:00

Enumerations vs. Pattern Matching

It is a bit redundant to have to use the same word twice in declarations like val Connect = Value("Connect").

Thanks.
— deanwampler (2009-07-12 22:13:32)

Comment on 'Enumerations vs. Pattern Matching'

2009-07-12T22:12:38-07:00

Enumerations vs. Pattern Matching

You are probably accustomed to using such names with Java or .NET enumerations. Unfortunately, we can’t get those names from the values in the Scala enumeration, at least given the way that we declared HttpMethod. However, there are two ways we can change the implementation to get name strings. In the first approach, we pass the name to Value when creating the fields.

thanks.
— deanwampler (2009-07-12 22:12:38)

Comment on 'Enumerations vs. Pattern Matching'

2009-07-12T22:11:34-07:00

Enumerations vs. Pattern Matching

The second use of Value is actually a call to a method. There is no namespace collision between these two names. The line val Connect, Delete, Get, Head, Options, Post, Put, Trace = Value defines the set of values for the enumeration. The Value method is called for each one. It creates a new Enumeration.Value for each one and adds it to the managed set of values.

Will fix
— deanwampler (2009-07-12 22:11:34)

Comment on 'Annotations'

2009-07-12T22:10:46-07:00

Annotations

All the constructor parameters must be constant expressions, including strings, class literals, Java enumerations, numerical expressions and one-dimensional arrays of the same. However, the compiler also allows annotation clauses with other arguments, such as boolean values and maps, as shown in this example.

I should add that the example compiles fine, but yes, having the keywords is not useful for the reasons discussed previously.
— deanwampler (2009-07-12 22:10:46)

Comment on 'Annotations'

2009-07-12T22:10:11-07:00

Annotations

Bug in the following example. Thanks.
— deanwampler (2009-07-12 22:10:11)

Comment on 'Annotations'

2009-07-09T07:07:20-07:00

Annotations

There is some description on "Did you notice that there is no val on uid?" above while the example below uses vals for annotation. This is a little confusing.
— parthm (2009-07-09 07:07:20)

Comment on 'Annotations'

2009-07-09T07:01:04-07:00

Annotations

Did you notice that there is no val on uid? Why isn’t uid a field? The reason is that the annotation’s data is not intended for use by the program. Recall that it is metadata designed for external tools to use, such as scalac. This also means that Scala annotations have no way to define default values in version 2.7.X, as implicit arguments don’t work. However, the new default arguments feature in version 2.8.0 may work. (It is not yet implemented at the time of this writing).

I don't know much about annotations but the scala compiler doesn't seem to product and error if val is used with annotation:
scala> class Bar(val x: Long) extends StaticAnnotation
defined class Bar
So is "val" silently ignored? Maybe it can be clarified.
— parthm (2009-07-09 07:01:04)

Comment on 'Design Patterns'

2009-07-01T11:44:15-07:00

Design Patterns

Let’s build a simple component model for an overly-simplified Twitter client. We want a configurable UI, a configurable local cache of past tweets, and a configurable connection to the Twitter service itself. Each of these “components” will be specified separately, along with a client component that will function as the “middleware” that ties the application together. The client component will depend on the other components. When we create a concrete client, we’ll configure in the concrete pieces of the other components that we need.

I've got to reread this, but I wanted to see an example that showed unit testing and "production" configuration of a single trait/component.

This pattern has always seemed a little abstract to me, and I hope this kind of example would ground it.
— jheintz (2009-07-01 11:44:15)

Comment on 'Enumerations vs. Pattern Matching'

2009-06-22T03:07:18-07:00

Enumerations vs. Pattern Matching

It is a bit redundant to have to use the same word twice in declarations like val Connect = Value("Connect").

to have to use the same word twice
— robcd (2009-06-22 03:07:18)

Comment on 'Enumerations vs. Pattern Matching'

2009-06-22T03:03:11-07:00

Enumerations vs. Pattern Matching

to doing <- using such names
— robcd (2009-06-22 03:03:11)

Comment on 'Enumerations vs. Pattern Matching'

2009-06-22T02:59:21-07:00

Enumerations vs. Pattern Matching

The first usage is actually
— robcd (2009-06-22 02:59:21)

Comment on 'Annotations'

2009-06-08T19:33:22-07:00

Annotations

Note the @throws annotation applied to the print method. The argument to the annotation constructor is a single java.lang.Class[Any] object, in this case, classOf[IOException]. The Java IO API methods used by print and the private method loop might throw this exception.

Good point. We want the code to be "good". I'll add the try/finally clause.
— deanwampler (2009-06-08 19:33:22)