The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

lutzhank (61) [Avatar] Offline
#1
MEAP 11/02/2010

1) 3.6 first paragraph second line
orig: "...classes could be appear..."

suggestion: "...classes could appear..." (deleted "be")

2) Second paragraph (sub paragraph) last sentence:
orig: "Both can take type parameters,...."

Because you talk about "traits can’t take any parameters", but in the next sentence here they could have type parameters, I suggest the word "though"
Therefore: "Both can take type parameters though,...."

3) Second paragraph (sub paragraph) last line
orig: "...discuss in the next chapter."

Reason for suggestion: To be able to search for references to chapter 4 later on and
the reader may feel lost in a whole chapter.

Suggestion: be more specific => "...discuss in section 4.1."

4) Third paragraph (second main paragraph) third line
orig: "...and a database is consists of multiple collections"

suggestion: "...and a database consists of multiple collections."

5) Third paragraph (second main paragraph), second last sentence
orig: "In Scala to do something like this we could use a trait."

Alternative description, which uses repetition and emphasizing more the language construct character of Scala:
"For slicing these views, Scala offers a construct known as trait."

6) Third main paragraph last line
orig: "...read-only collection interface will look."

suggestion: "...read-only collection interface will look like."

7) Third main paragraph second last line
orig: "...a read-only collection,..."

At this point of reading I had no problem with the naming of the trait "ReadOnly" representing a read only collection. But when I read about the "trait Updatable extends ReadOnly" in Listing 3.6 I couldn't let go of the violation of the "is a" relationship.

An Updatable being a ReadOnly was distracting.

Therefore suggestion: consider renaming it to e.g. "Reader" or "ReadingCollection". Then an "Updatable" could easily be a "ReadingCollection".

smilie First paragraph after Listing 3.5, second last line
orig: "...without using the . operator."

The "." could easily be overlooked (e.g. on my kindle) and I think it's not an operator but a delimiter (period) in the Scala syntax.

Therefore suggestion: "...without using the . (period)"

9) First paragraph after Listing 3.5, last line
orig: "...can invoke methods like the infix operator "

And not only operators with only one parameter (as I thought till now).

Therefore suggestion: "...can invoke any methods like an infix operator, though with multiple arguments these have to be put in parentheses e.g. "ScalaInAction" substring (7, 13)".

-------------------------------
Corrected MEAP version
Message was edited by: lutzhank