Polymorphic updates in an immutable class hierarchy

Question

I'd like to be able to assemble domain objects from traits, according to various properties that the concrete classes might have. When my objects are mutable, this is pretty straightforward. For example:

trait HasHitPoints { var hitPoints: Int = 100 }
trait HasBearing { var bearing: Double = 0 }

class Ship extends HasHitPoints with HasBearing
class Base extends HasHitPoints

val entities = new Ship :: new Base :: Nil
entities.collect { case h: HasHitPoints => h.hitPoints += 10 }

In particular, I can polymorphically read or update any HasHitPoints instance without knowing the concrete type.

What is the best way to implement this with immutable objects? If I'm happy to just read the properties, then I could do something like:

trait HasHitPoints { val hitPoints: Int }
trait HasBearing { val bearing: Double }

case class Ship(hitPoints: Int, bearing: Double) extends HasHitPoints with HasBearing
case class Base(hitPoints: Int) extends HasHitPoints

val things = Ship(50, 0) :: Base(100) :: Nil

val totalHitPoints = things.collect { case h: HasHitPoints => h.hitPoints }.sum

Also, I can easily modify the concrete classes using copy if I know the precise type. The hard part is updating an arbitrary HasHitPoints, for example. If I have lots of concrete classes, and lots of different properties I might like to mix-in, what's the best scheme to avoid an explosion of boilerplate code?

Answer 1

You may have some luck with adding an e.g. abstract def withHitPoints(points: Int) method to your traits, which returns a copy of the container object with a different property value. This reduces the usage to something like:

val damagedActors = actors map { actor => actor.withHitPoints( actor.hitPoints - 10 ) }

But will otherwise require an extra method per property per concrete class, so I'm not sure it really solves your problem. This does not feel right for a static language like Scala (nor would I likely bother with immutability for this particular use-case); an immutable solution here may be a better candidate for a dynamic language.

Answer 2

You are hoping to avoid the N update methods in M concrete classes. However painful I think this is just not possible. You will need access to the copy method or at least the constructor of every concrete class. Neither of them can be abstracted as is also discussed in: Case class copy() method abstraction So in the end you will always end up with the N x M 'boilerplate' code.