We had exercises on the list, but due to time constraints they won't make it into the first edition. Sorry about that. We've got that on the list for the second edition.

> [i looked around but didn't find a way to send general> site feedback? sorry for spamming here!] for long articles> like this, it would be great if the "comments" link from> the article went to the start of the comments, rather than> the re-print of the article which precedes the comments,> especially when the article is longer, like this...

> You described your path to Scala-ic code in your post on> the first release of ScalaTest, replacing SuiteRunner's> mutable state. How did the tests you wrote around> SuiteRunner/ScalaTest change as a result of your> decreasing reliance on mutable state?> OK. Basically, the way I'd summarize my current take on mutable state in Scala programs...

> > If you count the number of chars you save, it isn't> that> > much. I also added ImpSuite in 0.9.3, so that's the> > alternative if you prefer to be more concise. But I> hate> > to drive everyone to ImpSuite if what they're really> after> > is more conciseness.> >> Your reasoning here seems right to me - the added surface> area isn't nearly...

> Being very familiar with setUp/tearDown usage (and I> assume it's mostly syntax that has changed with> @Before/@After, not usage), I find it very frustrating to> duplicate fixture code in my test methods.> > Both the createFixture and withXxx alternatives force> identical calls to those structures in each test method,> something I...

In the most recent release of ScalaTest, I've placed some guidelines in the documentation for how to avoid the use of vars in testing code. In this post I include those guidelines and ask for feedback.

In the most recent release of ScalaTest, I've placed some guidelines in the documentation for how to avoid the use of <code>var</code>s in testing code. In this post I include those guidelines and ask for feedback.

In the most recent release of ScalaTest, I've placed some guidelines in the documentation for how to avoid the use of <code>var</code>s in testing code. In this post I include those guidelines and ask for feedback.

In the most recent release of ScalaTest, I've placed some guidelines in the documentation for how to avoid the use of vars in testing code. In this post I include those guidelines and ask for feedback.

> As in JUnit, is there no direct way to test private> methods?> http://www.artima.com/suiterunner/private.html>Yes, that's the case. What you can do is make a "Friend" class that exposes methods with the same API, which wrap the class under test and uses reflection to invoke the private methods. I've done that in a few places inside ScalaTest...

Sorry, the example in the book does not work with the current version ofScalaSwing. There are some incompatibilities having to do with Tables. These will be worked out in the next release of Scala and the book.Bill

Hi Blair,One other thing was that I got the names in the PrePrint2 acknowledgements from the Artima accounts of the people who posted comments. The names are public, so it fits within our privacy policy to display them. We display them on the profile page, for example. But they may not be real names. So I felt a bit funny about putting names of...

Hi Blair,We definitely appreciate all of your comments and those the other readers who submitted them. They have really helped a lot. At least at one point I think you had contributed the most. The reason we decided not to list all names in the final book was that it was just too many names, so we just thanked all of you without naming you...

> Anyone else notice that the index is only 3 pages?> > I would expect a 600+ page book to have more than three> pages in the index...The index isn't finished yet. It will be more substantial in the final version.

> Bill, in these languages that automatically give you> accessors, how do you make them immutable / read-only?> e.g. I want to allow> > > if (bill.age > 50)> startSendingAARPmaterials();> > > but not allow> > > bill.age = 21; // fake ID to allow Bill to buy beer> As James pointed out, in Scala you just say val instead of var. val defines a...