I wonder if the angst about case classes stems simply from the name. It is true that they can be used in case clauses of match expressions. However, to say that case classes are simply classes to be used in case clauses is missing the bigger picture. That’s essentially Daniel’s point.

What if everybody did a global, mental replacement of “case” with “bean”. Now we’re talking about bean classes. Does that make things any better?

Ok, so it looks like my article example is going to have to wait a bit longer (not happening this week). :-S I’ll try to summarize what I was thinking:

Pattern matching allows boolean testing *and* extraction of data in a single operation. It’s like the old-fashioned dynamic_cast in C++, which combines Java’s instanceof and cast operations. This saves on the amount of typing of course, but it also makes things a little less typo-prone. For example, consider the example of the immutable List. In Scala, this is implemented using a case class (::) and a case object (Nil):

def sum(list: List[Int]): Int = list match {
case hd :: tail => hd + sum(tail)
case Nil => 0
}

The pattern matching handles two operations in one: it checks to see if the list has any remaining elements and binds the first such element and the remainder of the list to the hd and tail constants (respectively). If we tried to write this without pattern matching, it would look something like this:

def sum(list: List[Int]): Int = {
if (list.length > 0) {
list.head + sum(list.tail)
} else 0
}

The problem here is that our conditional body is not *compile time* constrained to only deal with the list as a head and tail. All we know about this list is that it has at least one element, so we should only work with the element we know exists (at index 0). It is possible at compile time to access the list deeply. While this is of course possible in our first example (by accessing list directly), it is not as easy to do (in terms of typographical or even logical errors).

Pattern matching is inextricably linked to the more compelling uses for case classes, so I suppose that it is true that you cannot deeply consider one without the other. Neither is a hard necessity, since it is certainly possible in Scala to write code which avoids pattern matching (and case classes) altogether. The question is: why would you want to? As language features, they save on code noise, they reduce the potential for subtle logic errors (like selecting the wrong index), in every way I can think of they represent a benefit. Can the technique be over-used and applied to situations where polymorphism is better suited? Yes it can, but that would not be a “correct” application of the construct. It’s just another tool which simplifies some unfortunately common scenarios.

Fair enough. I wasn’t aware that the compiler will supply the necessary bits of the companion object, so that keeps the overhead down and gives the flexibility one might need. I should have known. Scala seems particularly good at just letting you express the things you need and dealing with all the rest automatically.

You can override apply() in your companion object to perform caching, and that’s precisely what we’re suggesting you do for immutable objects. The compiler could certainly perform deep analysis to determine immutability, but as James pointed out, actually implementing a caching mechanism based on that analysis alone would be presumptuous to say the least. How is the compiler to know what your program should be optimized for (space vs time)? At least GCC and friends define a -O parameter to hint at this sort of thing, but even that does not control transparent caching or its ilk.

As an extreme example of how such transparent caching could go wrong, let’s assume that you’re working on some sort of data-mining application involving the creation of *billions* of immutable objects, each slightly different from the other. Each of these objects is used briefly, then goes out of scope. What happens if the compiler injects caching into this scenario? Answer: memory usage shoots through the roof, the heap overflows and your application crashes after only a few hundred thousand objects. Even the smartest analysis can’t be trusted to make the final decision on *what* scenario you want to optimize your application for, it can only make guesses. Basic optimizations (constant folding, tail-call folding, etc) are almost “no-brainers” that apply in all cases, but something as high-level as an object cache would be very dangerous to try to do automatically.

Fair enough, but the caching is something which could be handled by the companion object. Having to build your own companion object to do this would seem to me to defeat half the benefit of using case classes in this way. The compiler could probably determine if the case class was deeply immutable (i.e. all it’s instance variable were var and deeply immutable) and provide an option in some way to say to use common instances. I’m thinking of a particular case I’ve dealt with in a java program where I built the cache myself to optimise away the generation of vast numbers of immutable objects with the same values that was causing serious overhead. It just seems a missed opportunity to let the language take care of this automatically in some way.

BTW, if I want to override the auto-generated companion object is it just a matter of defining it and the compiler will use my definition instead?

Even if it did, there would be practical limitations similar to the way string values can be shared. For instance, it would probably only be able to share instances that were created from the same literals (or things that the compiler knew how to fold into the same literal like “Do” + “ug”). Trying to share instances created from variables would require a runtime cache which is normally considered something to be left in the hands of a programmer because it creates important differences in runtime space/time trade-offs.

val me = Person(“Doug”, “Clinton)
val meAgain = Person(“Doug”, “Clinton”)

and assuming that the immutable form of case class is used, will this result in the creation of two objects, or will me and meAgain refer to the same instance of Person?

Oh, I see what you mean. In principle, I agree with you. Unfortunately, there have been situations where I have needed that time variant property in the object identity. I can’t remember an exact scenario, but I believe it had something to do with caching and multi-maps.

In general though, mutable containers should use object id-based implementations of equals and hashCode, while containers which require equals/hashCode to be formed based on contents should ensure immutability. As Doug pointed out, it is the difference between a datatype and an entity.