so

class Book(val title:String) {
private var author:Author = null

def Author = author

def Author_=(authorP:Author) {
if (authorP != null) {
author = authorP
}
}
}

I use suffix P to distinguish parameters from fields so I can avoid using “this”. Any thoughts?

In this case, != would be a member of author. However, Scala does avoid the whole null equality issue very nicely by making null a value of type Null, which does define the == and != methods. Thus, the following works perfectly:

val t: String = null
t != null   // => false
t == null  // => true
null == null  // => true

Gotta love Scala!

That all said, I ended up here looking for a way of Null checking in scala, and the comments did give the clear answer, don’t use null, use Option[...] instead; makes sense.

However, your scala sample uses

if (author != null) …
.
As far as i understand ‘!=’ is actually a function so I would expect that when author is null there to be a NullPointerException thrown attempting to evaluate a member (‘!=’) of null.

Or dose scala treat null as a real object, supporting all the standard functions?

Definitely +1 the use of Option over nullable values. The mutable field (author) is a bit unidiomatic however, especially for a case class. It’s pretty good though.

I think that the more significant issue to resolve in Scala design idioms is how to deal with name classes, particularly in fields and methods. There was some discussion about this above, leading vs trailing underscores, suffixes, etc.

case class Book( title:Option[String]) { var author:Option[Author]=None }

1. handles title constructor
2. handles avoiding null in favor of Option
3. author is R/W

usage:

var b = Book( Some(“Fahrenheit 451″) )
b.author = Some( Author(“Ray Bradbury”) )

I agree with the goal in your concluding paragraph, but wonder how much history/experience a language community needs before starting to converge on “best practice” style and idiom conventions. (I recall criticisms of new-born Ada, asserting that the designers had attempted to standardize areas which were not sufficiently well-understood.) Finally, I wonder whether multiple styles may emerge in the use of a hybrid language, a Java-like style in code that’s primarily OO, along with a Haskell-like style in code that’s primarily FP. It’s going to be interesting to watch this develop!

Well, but that would highlight the topic much more, as mostly idioms result from specific syntax features available in different languages. That is exactly what makes learning a new language so hard, when trying to avoid writing your “old language” only in another syntax.

So both examples of Ruby are useful to show the point.

Well, this article may be the first step of a long series, as in my opinion the ‘uncertainty what is “the right way” ‘ reg. Scala indeed involves the bigger part, especially as it is based on Java.

I just hit the problem with: “Yes, I know how to open a file and iterate through the lines in Java. Yes, it all worked when likewise done in Scala syntax. But is scaladish Java the intented way to do it?”

The %* syntax was actually considered for deprecation in 1.9, so I’m not sure it can be considered to be “more idiomatic”. You’re write about the one-line Proc though. I thought about using it, but I’ve always though that “brace blocks” are less readable than then do/end syntax and I didn’t feel like trying to explain Ruby syntax elements in a post about Scala.

first_names = %w{Daniel Chris Joseph}

first_names.each { |name| puts name }