Comments on Programming Scala

Comment on 'Enumerations'

2009-07-29T05:18:01-07:00

Enumerations

Running this script with scala yields the following output.

thought I mention this, others might run into the same question, on
     val Mon, Tue, Wed, Thu, Fri, Sat, Sun = Value
   
in Java Object i, j = new Object()

is only an initialization of j, i remain uninitialized. It makes sense that all the enumerations are initialized in scala given the preference for val.
— maddalab (2009-07-29 05:18:01)

Comment on 'Pattern Matching'

2009-07-29T04:56:47-07:00

Pattern Matching

Instead, consider using pattern matching for those “rare” times when you need to extract information in a controlled way. An unapply method can hide the implementation details of the objects it is decomposing. In fact, the information returned by unapply might be a transformation of the actual information in the type.

ehh unapply?? first reference to the method. I had to go look up the scala documentation on extractor objects

http://www.scala-lang.org/node/112

to understand that line.
— maddalab (2009-07-29 04:56:47)

Comment on 'Pattern Matching'

2009-07-29T04:45:15-07:00

Pattern Matching

The case objects are just singleton objects like we’ve seen before, but with the special case behavior. We’re most interested in the embedded p @ Person(…) inside the case clause. We’re matching on particular kinds of Person objects inside the enclosing tuple. We also want to assign the Person to a variable p, so we can use it for printing.

format from Predef from Console.format is deprecated, also using 2.8 REPL does not result in any output on the REPL

Since this is the last example with pattern matching, thought I would mention that I do not recall an example the demonstrates using the result of a match expression.

Match expressions return the result of the evaluated case, building on your example I came up with this
           val allemps = Map(1->alice, 2->bob, 3->charlie)
           val pooremps = allemps.filter(_ match {case (id, p @ Person(_, , Manager)) => false
                case (id, p @ Person(, , )) => true})

    for(e <- pooremps)
      println(e)
— maddalab (2009-07-29 04:45:15)

Comment on 'Pattern Matching'

2009-07-29T03:21:47-07:00

Pattern Matching

This type of pattern match becomes extremely useful when working with Actors, as we’ll see later on. Case classes are frequently sent to Actors as messages, and deep pattern matching on an object’s contents is a convenient way to "parse" those messages.

hopefully formats better this time

   case class Address(location:String, city:String, state:String)
   case class Person(address:Address, name:String, age:Int)

val bhaskar = new Person(new Address("Hookey lane", "Wonderland", "Chocolate Factory"), "Bhaskar", 8726)
   val dave = new Person(new Address("Mills Road", "Wilmington", "Delaware"), "David", 53553)

for(p <- List(bhaskar, dave)){
     p match {
       case Person(Address(_, city, "Chocolate Factory"), name, age) => println("Whoo hoo " + name + ", " + age + " still lives in Chocolate Factory, never grew up")
       case Person(Address(_, city, state), name, age) if (age > 10000) => println(name + " from city " + city + " and state " + state + " is " + age + " ollllldddd ") 

    case Person(_,_,_) => println("You are just boring")
     }
   }

— maddalab (2009-07-29 03:21:47)

Comment on 'Pattern Matching'

2009-07-29T03:21:10-07:00

Pattern Matching

The section on case classes repeatedly mentions "deep pattern matching" but the selected example is not different from the ones in previous section and does not demonstrate any deep matching

case class Address(location:String, city:String, state:String) case class Person(address:Address, name:String, age:Int)

val bhaskar = new Person(new Address("Hookey lane", "Wonderland", "Chocolate Factory"), "Bhaskar", 8726) val dave = new Person(new Address("Mills Road", "Wilmington", "Delaware"), "David", 53553)

for(p <- List(bhaskar, dave)){ p match { case Person(Address(_, city, "Chocolate Factory"), name, age) => println("Whoo hoo " + name + ", " + age + " still lives in Chocolate Factory, never grew up") case Person(Address(_, city, state), name, age) if (age > 10000) => println(name + " from city " + city + " and state " + state + " is " + age + " ollllldddd ")
case Person(_,_,_) => println("You are just boring") } }
— maddalab (2009-07-29 03:21:10)

Comment on 'Pattern Matching'

2009-07-29T03:08:05-07:00

Pattern Matching

We first define a case class, a special type of class that we’ll learn more about in the section called “Case Classes” in Chapter 6, Advanced Object-Oriented Programming In Scala. For now, it will suffice to say that a case class allows for very terse construction of simple objects with some pre-defined methods. Our pattern match then looks for Alice and Bob by inspecting the values passed to the constructor of the Person case class. Charlie falls through to the catch-all case; even though he has the same age value as Bob, we’re matching on the name property as well.

I noticed that the use of "default" and "catch-all" is inconsistent, had to go back and read the section, the two words are used to mean the case thing.

However I think one should be use for

case _ (catch-all)

and the other for

case Person(name, age) -> default

Keeps the ducks lined up, right now they are all over the place
— maddalab (2009-07-29 03:08:05)

Comment on 'Pattern Matching'

2009-07-29T02:51:04-07:00

Pattern Matching

The second case matches the empty list, Nil. It prints an end of line and terminates the recursion.

Any reason the second case specifically uses Nil ove

case List()
— maddalab (2009-07-29 02:51:04)

Comment on 'Pattern Matching'

2009-07-28T04:33:42-07:00

Pattern Matching

It looks just like a C-style case statement, right? The only difference is the last case with the underscore ‘_’ wild card. It matches anything not defined in the cases above it, so it serves the same purpose as the default keyword in Java and C# switch statements.

I thinks

val bools = List(true, false)

should be

val bools = List(true, false, 1)

to demonstrate the catch-all case.

In the first case bools is inferred to by List[Boolean] and in the second List[AnyVal]
— maddalab (2009-07-28 04:33:42)

Comment on 'Other Looping Constructs'

2009-07-28T04:22:26-07:00

Other Looping Constructs

Yup, that’s all that’s necessary. This clean one-liner is possible because of Scala’s RichInt class. An implicit conversion is invoked by the compiler to convert the 1, an Int, into a RichInt. (We’ll discuss these conversions in the section called “The Scala Type Hierarchy” in Chapter 7, The Scala Object System and in the section called “Implicit Conversions” in Chapter 8, Functional Programming in Scala.) RichInt defines a to method that takes another integer and returns an instance of Range.Inclusive. That is, Inclusive is a nested class in the Range companion object (a concept we introduced briefly in Chapter 1, Zero to Sixty: Introducing Scala; see Chapter 6, Advanced Object-Oriented Programming In Scala for details). This subclass of the class Range inherits a number of methods for working with sequences and iterable data structures, including those necessary to use it in a for loop.

RichInt defines a to method that takes another integer and returns an instance of Range.Inclusive. That is, Inclusive is a nested class in the Range companion object

I do not understand how you draw the implication (using That is) that we are using the Range companion object and not the class
— maddalab (2009-07-28 04:22:26)

Comment on 'Scala if Statements'

2009-07-28T02:51:12-07:00

Scala if Statements

Note that configFilePath is now Unit. (It was String before.) The type inference picks a type that works for all outcomes of the if expression. Unit is the only possibility, since no value is one possible outcome.

This is incorrect (at least in 2.8)

the type of the if expression is inferred to be Any and the result could be either the String or Unit. This seem more correct as Unit is value and not a type

scala> ().isInstanceOf[Any]
res37: Boolean = true

scala> val configFile = new java.io.File("~/.myapprc") configFile: java.io.File = ~/.myapprc

scala> val configFilePath = if (configFile.exists()) { | configFile.getAbsolutePath()
| }
configFilePath: Any = ()
— maddalab (2009-07-28 02:51:12)

Comment on 'Domain-Specific Languages'

2009-07-28T02:24:40-07:00

Domain-Specific Languages

Notice how much this code reads like English: “this should test that in the following scenario”, “this value must equal that value”, and so forth. This example uses the superb Specs library, which effectively provides a DSL for the behavior-driven development testing and engineering methodology. By making maximum use of Scala’s liberal syntax and rich methods, Specs test suites are readable even by non-developers.

Currently specs builds with scala 2.7 version and the jar obtained from the specs website cannot be used with scala 2.8

So, tho this example makes sense, there is no way to try it out at this time
— maddalab (2009-07-28 02:24:40)

Comment on 'Methods Without Parentheses and Dots'

2009-07-28T01:49:45-07:00

Methods Without Parentheses and Dots

To facilitate a variety of readable programming styles, Scala is flexible about the use of parentheses in methods. If a method takes no parameters, you can define it without parentheses. Callers must invoke the method without parentheses. If you add empty parentheses, then callers may optionally add parentheses. For example, the size method for List has no parentheses, so you write List(1, 2, 3).size. If you try List(1, 2, 3).size(), you’ll get an error. However, the length method for String does have parentheses in its definition, so both "hello".length() and "hello".length will compile.

I think it might be useful to note that this allow for flexibility of implementation

List(1,2,3).size

allows for size to be implemented as either a method or a member field

def size = 10

val size = 10

the client would not have to change when the underlying implementation is changed. I think this has been stated at a few places as "Scala's uniform access principle"
— maddalab (2009-07-28 01:49:45)

Comment on 'Conditional Operators'

2009-07-26T04:38:19-07:00

Conditional Operators

Table 3.1. Conditional Operators

Operator	Operation	Description
`&&`	and	The values on the left and right of the operator are true. The right-hand side is only evaluated if the left-hand side is true.
`\|\|`	or	At least one of the values on the left or right is true. The right-hand side is only evaluated if the left-hand side is false.
`>`	greater than	The value on the left is greater than the value on the right.
`⇒`	greater than or equals	The value on the left is greater than or equal to the value on the right.
`<`	less than	The value on the left is less than the value on the right.
`⇐`	less than or equals	The value on the left is less than or equal to the value on the right.
`==`	equals	The value on the left is the same as the value on the right.
`!=`	not equal	The value on the left is not the same as the value on the right.

The greater than or equals operator should be >=, not =>, I guess.
— jannic (2009-07-26 04:38:19)

Comment on 'Pattern Matching'

2009-07-15T14:22:12-07:00

Pattern Matching

It first matches on head :: tail, where head will be assigned the first element in the list and tail will be assigned the rest of the list. That is, we’re extracting the head and tail from the list using ::. When this case matches, it prints the head and calls processList recursively to process the tail.

There's nothing after "using" in the sentence: "...extracting the head and tail from the list using."
— jrduncans (2009-07-15 14:22:12)

Comment on 'Other Looping Constructs'

2009-07-15T13:55:18-07:00

Other Looping Constructs

As it turns out, there’s a more elegant way to loop through collections in Scala, as we’ll see in the next section.

This example doesn't loop through a collection, it loops over a range. And we saw looping over a collection in an earlier section.
— jrduncans (2009-07-15 13:55:18)

Comment on 'Pattern Matching'

2009-07-15T13:19:37-07:00

Pattern Matching

You could use "p: Person" instead of "p @ Person(_, _, )" for the second case statement. You might also want to either use id or replace it with "".
— GatesDA (2009-07-15 13:19:37)

Comment on 'Other Looping Constructs'

2009-07-15T06:47:04-07:00

Other Looping Constructs

However, because of demand for it, Scala version 2.8 includes support for break, implemented as a library method, rather than a built-in break keyword.

The main text should read well on its own if the notes are moved to a sidebar, skipped by the reader, or otherwise taken out of flow. I would either move the comment on 2.8's break method in with the note, or change the note to be part of the main text.
— GatesDA (2009-07-15 06:47:04)

Comment on 'Pattern Matching'

2009-07-12T21:14:12-07:00

Pattern Matching

Thanks. will fix.
— deanwampler (2009-07-12 21:14:12)

Comment on 'Pattern Matching'

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

Pattern Matching

In the second case in this example, we’ve extracted the values inside the tuple to scoped variables, then reused these variables in the resulting expression.

Thanks. will clarify.
— deanwampler (2009-07-12 21:04:22)

Comment on 'Other Looping Constructs'

2009-07-12T20:56:41-07:00

Other Looping Constructs

@Mario. True. Will add something about the conversion. @Javier. You're right, although technically foreach and for loops are different constructs.
— deanwampler (2009-07-12 20:56:41)

Comment on 'Scala for Comprehensions'

2009-07-12T20:50:48-07:00

Scala for Comprehensions

As you might guess, this code says “for every element in the List dogBreeds, create a temporary variable called breed with the value of that element, then print it.” Think of the <- operator as an arrow directing elements of a collection, one-by-one, to the scoped variable by which we’ll refer to them inside the for expression. The left-arrow operator is called a generator, so named because it’s generating individual values from a collection for use in an expression.

We have examples later on.
— deanwampler (2009-07-12 20:50:48)

Comment on 'Methods Without Parentheses and Dots'

2009-07-12T20:49:26-07:00

Methods Without Parentheses and Dots

Your confirming what the text says. List(...).size is fine, but not List(...).size(). The methods on java.lang.String with no arguments are defined with (), as required by Java, but Scala lets you drop those parentheses, as in your example.
— deanwampler (2009-07-12 20:49:26)

Comment on 'Operator? Operator?'

2009-07-12T20:43:28-07:00

Operator? Operator?

Pattern Matching Identifiers

Thanks. will fix.
— deanwampler (2009-07-12 20:43:28)

Comment on 'Operator? Operator?'

2009-07-12T20:43:08-07:00

Operator? Operator?

So, what characters can you use in identifiers? Here is a summary of the rules for identifiers, used for method and type names, variables, etc. For the precise details, see [ScalaSpec2009]. Scala allows all the printable ASCII characters, such as letters, digits, the underscore ‘_’, and the dollar sign ‘$’, with the exceptions of the “parenthetical” characters, ‘(’, ‘)’, ‘[’, ‘]’, ‘{’, ‘}’, and the “delimiter” characters ‘`’, ‘’’, ‘'’, ‘"’, ‘.’, ‘;’, and ‘,’. Scala allows the other characters between \u0020-\u007F that are not in the sets above, such as mathematical symbols and “other” symbols. These remaining characters are called operator characters and they include characters such as ‘/’, ‘<’, etc.

We "informally" list them in the glossary under "operator characters".
— deanwampler (2009-07-12 20:43:08)

Comment on 'Operator? Operator?'

2009-07-12T20:41:31-07:00

Operator? Operator?

That plus sign between the numbers? It’s a method. First, Scala allows non-alphanumeric method names. You can call methods +, -, _$_, or whatever you desire. Second, this expression is identical to 1.+(2). When a method takes one argument, Scala lets you drop both the period and the parentheses, so the method invocation looks like an operator invocation. This is called “infix” notation, where the operator is between the instance and the argument. We’ll find out more about this shortly.

Well, we certainly imply this by saying "between the instance and the argument".
— deanwampler (2009-07-12 20:41:31)

Comment on 'Pattern Matching'

2009-07-09T03:00:51-07:00

Pattern Matching

Here we pull each element out of a List of Any type of element, in this case containing a String, a Double, an Int, and a Char. For the first three of those types, we let the user know specifically which type we got and what the value was. When we get something else (the Char), we just let the user know the value. We could add further elements to the list of other types and they’d be caught by the other wild card case.

You might want to add at least one operation unique to one of the types to make it crystal clear that using a variable gives you some benefit. Like change the 's' case to this:

case s: String => println("got a String of length " + s.length)

Then call attention to the fact that sundry.length doesn't compile but s.length does.
— wrburdick (2009-07-09 03:00:51)

Comment on 'Pattern Matching'

2009-07-09T02:56:33-07:00

Pattern Matching

In this example, we assign the wild card case to a variable called otherNumber, then print it in the subsequent expression. If we generate a seven, we’ll extoll that number’s virtues. Otherwise, we’ll curse fate for making us suffer an unlucky number.

I think the use of variables in "Matching on Type" example is clearer than the above, because you gain something by using a variable there (like being able to perform string operations). It was confusing to me what the difference between 'otherNumber' and 'randomInt' was.
— wrburdick (2009-07-09 02:56:33)

Comment on 'Methods Without Parentheses and Dots'

2009-07-07T00:10:19-07:00

Methods Without Parentheses and Dots

List(1,2,3).size does not result in an error. Scala allows you omit () parenthesis. For example, scala> "hello World".toLowerCase.toUpperCase res3: java.lang.String = HELLO WORLD
— ajaykumarns (2009-07-07 00:10:19)

Comment on 'Other Looping Constructs'

2009-06-30T08:48:22-07:00

Other Looping Constructs

You can find a table of the conditional operators that work in while loops below.

I'm puzzled; why don't all conditional operators work in while loops? Or do you cover that later as well?
— diathesis (2009-06-30 08:48:22)

Comment on 'Pattern Matching'

2009-06-20T11:12:04-07:00

Pattern Matching

is a convenient way
— robcd (2009-06-20 11:12:04)

Comment on 'Operator? Operator?'

2009-06-20T08:56:12-07:00

Operator? Operator?

Pattern Matching Identifiers

reckon you meant 'that begin with' instead of 'being with' - both times
— robcd (2009-06-20 08:56:12)

Comment on 'Other Looping Constructs'

2009-06-14T16:03:02-07:00

Other Looping Constructs

"That's all that's necessary" is misleading, the i variable is not necessary, you can do just

(1 to 10) foreach println
— javiervegeas (2009-06-14 16:03:02)

Comment on 'Pattern Matching'

2009-06-10T22:20:10-07:00

Pattern Matching

In the second case in this example, we’ve extracted the values inside the tuple to scoped variables, then reused these variables in the resulting expression.

Consider clarifying the below Tip portion "or a meaningfully-named variable" to explain that it must not have a type declaration, the lack of type declaration is what allows it to be bound to anything.
— stevej (2009-06-10 22:20:10)

Comment on 'Operator? Operator?'

2009-06-10T21:43:31-07:00

Operator? Operator?

By 'this', I meant all the operator characters.
— stevej (2009-06-10 21:43:31)

Comment on 'Operator? Operator?'

2009-06-10T21:41:47-07:00

Operator? Operator?

This would be great to list in an appendix.
— stevej (2009-06-10 21:41:47)

Comment on 'Other Looping Constructs'

2009-06-10T08:06:10-07:00

Other Looping Constructs

When mentioning RichInt, should'nt there be also a short explanation on how that Int gets converted into RichInt (that is using Predefs given implicits / implicit type conversion) ?
— magle (2009-06-10 08:06:10)

Comment on 'Scala for Comprehensions'

2009-06-10T07:56:39-07:00

Scala for Comprehensions

Maybe you could note, that it's possible to apply more than one Generator within a single for comprehension, like for( friend <- petFriends; breed <- dogBreeds; ... ){ ... }
— magle (2009-06-10 07:56:39)

Comment on 'Operator? Operator?'

2009-06-10T04:37:51-07:00

Operator? Operator?

There's another constraint for droping the period and the parentheses: the receiver of the method have to be mentioned explicitly.

E.g. it's not possible to call a method inside a class in the above way ( like '+ 2' within class Int), without explicitly using 'this' as the receiver of the method (thus only valid if used like 'this + 2'). This is also true for imported methods of objects - you can't write 'println "ho"', but also have to mention the receiver explicitly.
— magle (2009-06-10 04:37:51)

Comment on 'Enumerations'

2009-06-07T18:59:54-07:00

Enumerations

Case classes (see the section called “Case Classes” in Chapter 6, Advanced Object-Oriented Programming In Scala) are often used instead of enumerations in Scala, because the “use case” for them often involves pattern matching. We’ll revisit this topic in the section called “Enumerations vs. Pattern Matching” in Chapter 13, Application Design.

Fixed the cross reference. Will add note about enums vs. case classes.
— deanwampler (2009-06-07 18:59:54)

Comment on 'Pattern Matching'

2009-06-07T18:55:05-07:00

Pattern Matching

Pattern matching aside, Scala’s treatment of exception handling should be familiar to those fluent in Java, Ruby, Python, and most other mainstream languages. And yes, you throw an exception by writing throw new MyBadException(…). That’s all there is to it.

Good point. Will add a statement to that effect.
— deanwampler (2009-06-07 18:55:05)

Comment on 'Pattern Matching'

2009-06-11T06:39:36-07:00

Pattern Matching

Let’s try a deep match, examining the contents of objects in our pattern match.

Thought more about it; will add a "note" to encourage thinking more careful about why you might have "none of the above" and make sure it's really the right thing to do.
— deanwampler (2009-06-11 06:39:36)

Comment on 'Pattern Matching'

2009-06-11T06:39:36-07:00

Pattern Matching

Let’s try a deep match, examining the contents of objects in our pattern match.

Will clarify the wording.
— deanwampler (2009-06-11 06:39:36)

Comment on 'Pattern Matching'

2009-06-07T18:47:06-07:00

Pattern Matching

In the second case of we’ve used a special wild card pattern to match a List of any size, even zero elements, and any element values. You can use this pattern at the end of any sequence match to remove length as a condition.

Will fix. Thanks.
— deanwampler (2009-06-07 18:47:06)

Comment on 'Pattern Matching'

2009-06-07T18:46:36-07:00

Pattern Matching

An idea borrowed from functional languages, pattern matching is a powerful yet concise way to make a programmatic choice between multiple conditions. Pattern matching is the familiar case statement from your favorite C-like language, but on steroids. In the typical case statement you’re limited to matching against values of ordinal types, yielding trivial expressions like this: "in the case that i is 5, print a message; in the case that i is 6, exit the program". With Scala’s pattern matching, your cases can include types, wild-cards, sequences, and even deep inspections of an object’s variables.

We get into this later.
— deanwampler (2009-06-07 18:46:36)

Comment on 'Other Looping Constructs'

2009-06-07T18:45:31-07:00

Other Looping Constructs

You can find a table of the conditional operators that work in while loops below.

Good point! We like the example, so we'll add a warning comment!
— deanwampler (2009-06-07 18:45:31)

Comment on 'Scala for Comprehensions'

2009-06-07T18:44:46-07:00

Scala for Comprehensions

Every time through the for expression, the filtered result is yielded as a value named breed. These results accumulate with every run, and the resulting collection is assigned to the value filteredBreeds (as we did with if statements above). The type of the collection resulting from a for-yield expression is inferred from the type of the collection being iterated over. In this case, filteredBreeds is of type List[String], since it is a subset of the dogBreeds list, which is also of type List[String].

Will expand the tip briefly. Short answer, people almost always use {}.
— deanwampler (2009-06-07 18:44:46)

Comment on 'Scala for Comprehensions'

2009-06-07T18:38:39-07:00

Scala for Comprehensions

Another familiar control structure that’s particularly feature-rich in Scala is the for loop, referred to in the Scala community as a for comprehension or for expression. This corner of the language deserves at least one fancy name, because it can do some great party tricks.

Will add a brief description
— deanwampler (2009-06-07 18:38:39)

Comment on 'Scala if Statements'

2009-06-07T18:38:12-07:00

Scala if Statements

Because if statements are expressions in Scala, there is no need for the special-case ternary conditional expressions that exists in C-derived languages. You won’t see x ? doThis() : doThat() in Scala. Scala provides a mechanism that’s just as powerful and more readable.

Reworded a bit.
— deanwampler (2009-06-07 18:38:12)

Comment on 'Scala if Statements'

2009-06-07T18:10:55-07:00

Scala if Statements

Note that if statements are expressions, meaning they have values. In this example, the value configFilePath is the result of an if expression that handles the case of a configuration file not existing internally, then returns the absolute path to that file. This value can now be reused throughout an application, and the if expression won’t be re-evaluated when the value is used.

Thanks, both of you, for these comments. Will clarify.
— deanwampler (2009-06-07 18:10:55)

Comment on 'Methods Without Parentheses and Dots'

2009-06-07T18:09:56-07:00

Methods Without Parentheses and Dots

So, if an expression like 2.0 * 4.0 / 3.0 * 5.0 is actually a series of method calls on Doubles, what are the operator precedence rules? Here they are in order from lowest to highest precedence [ScalaSpec2009].

Yea, it did. Will fix.
— deanwampler (2009-06-07 18:09:56)

Comment on 'Pattern Matching'

2009-06-02T06:23:34-07:00

Pattern Matching

It may be good to mention that pattern matching is different from regular expressions. Readers who haven't been exposed to functional programming may not be aware of pattern matching and may think of this as something to do with regex.
— parthm (2009-06-02 06:23:34)

Comment on 'Other Looping Constructs'

2009-06-02T06:15:59-07:00

Other Looping Constructs

You can find a table of the conditional operators that work in while loops below.

You could consider tweaking the above example to be runnable in the REPL.

I pasted this one into the REPL before realizing that I can't really run it as it sleeps for a day as indicated in the comment. I had to kill the REPL.
— parthm (2009-06-02 06:15:59)

Comment on 'Scala for Comprehensions'

2009-06-02T06:08:21-07:00

Scala for Comprehensions

Regarding the "Tip" above (parens or braces). Is there a recommendation on what is preferred or common in Scala community?
— parthm (2009-06-02 06:08:21)

Comment on 'Scala for Comprehensions'

2009-06-02T06:01:35-07:00

Scala for Comprehensions

Maybe it can be briefly described why for is referred to as "comprehension" and not "loop".
— parthm (2009-06-02 06:01:35)

Comment on 'Methods Without Parentheses and Dots'

2009-06-02T05:52:39-07:00

Methods Without Parentheses and Dots

operator precedence'' rules? The followingscala The markup for the text above seems to have gone bad.

— parthm (2009-06-02 05:52:39)

Comment on 'Pattern Matching'

2009-05-21T04:18:28-07:00

Pattern Matching

This example is a bit confusing. The message in the second case is not exact -- a list of [1, 3] would also print this.
— retronym (2009-05-21 04:18:28)

Comment on 'Enumerations'

2009-05-20T13:05:53-07:00

Enumerations

Revisit in where? (the chapter number is missing)

Btw. you probably should mention that instead of Enumeration, often case classes are used.
— clojure (2009-05-20 13:05:53)

Comment on 'Pattern Matching'

2009-05-20T13:02:01-07:00

Pattern Matching

I don't see a clear, explicit mention that exceptions are not checked, which I think is important to know for people coming from Java land.
— clojure (2009-05-20 13:02:01)

Comment on 'Pattern Matching'

2009-06-11T06:39:36-07:00

Pattern Matching

Let’s try a deep match, examining the contents of objects in our pattern match.

"It is often helpful to include a catch-all case"

I don't think _ should be encouraged. If one later adds another case class, there's a good change some method won't be updated. Even if not that, it's better to be explicit... it's way more readable (of course, there are exceptions)
— clojure (2009-06-11 06:39:36)

Comment on 'Scala if Statements'

2009-05-20T12:46:59-07:00

Scala if Statements

Huh? How does it clutter up it anymore than if-then-else? Though, I admit the latter being a bit more readable.
— clojure (2009-05-20 12:46:59)

Comment on 'Scala if Statements'

2009-05-20T12:43:57-07:00

Scala if Statements

"return" is not very good choice of word, I think. "Note that if statement is an expression, which evaluates to a value" sounds better to me.
— clojure (2009-05-20 12:43:57)

Comment on 'Scala if Statements'

2009-05-20T04:04:33-07:00

Scala if Statements

Perhaps point out that this only makes sense in an if / else. Scala allows val x = if true 1; but it returns ().
— retronym (2009-05-20 04:04:33)