27

My present use case is pretty trivial, either mutable or immutable Map will do the trick.

Have a method that takes an immutable Map, which then calls a 3rd party API method that takes an immutable Map as well

def doFoo(foo: String = "default", params: Map[String, Any] = Map()) {

  val newMap = 
    if(someCondition) params + ("foo" -> foo) else params

  api.doSomething(newMap)
}

The Map in question will generally be quite small, at most there might be an embedded List of case class instances, a few thousand entries max. So, again, assume little impact in going immutable in this case (i.e. having essentially 2 instances of the Map via the newMap val copy).

Still, it nags me a bit, copying the map just to get a new map with a few k->v entries tacked onto it.

I could go mutable and params.put("bar", bar), etc. for the entries I want to tack on, and then params.toMap to convert to immutable for the api call, that is an option. but then I have to import and pass around mutable maps, which is a bit of hassle compared to going with Scala's default immutable Map.

So, what are the general guidelines for when it is justified/good practice to use mutable Map over immutable Maps?

Thanks

EDIT so, it appears that an add operation on an immutable map takes near constant time, confirming @dhg's and @Nicolas's assertion that a full copy is not made, which solves the problem for the concrete case presented.

virtualeyes
  • 11,147
  • 6
  • 56
  • 91
  • 4
    See [Extreme Cleverness: Functional Data Structures in Scala](http://www.infoq.com/presentations/Functional-Data-Structures-in-Scala). – Daniel C. Sobral Apr 13 '12 at 15:44

4 Answers4

44

Depending on the immutable Map implementation, adding a few entries may not actually copy the entire original Map. This is one of the advantages to the immutable data structure approach: Scala will try to get away with copying as little as possible.

This kind of behavior is easiest to see with a List. If I have a val a = List(1,2,3), then that list is stored in memory. However, if I prepend an additional element like val b = 0 :: a, I do get a new 4-element List back, but Scala did not copy the orignal list a. Instead, we just created one new link, called it b, and gave it a pointer to the existing List a.

You can envision strategies like this for other kinds of collections as well. For example, if I add one element to a Map, the collection could simply wrap the existing map, falling back to it when needed, all while providing an API as if it were a single Map.

dhg
  • 52,383
  • 8
  • 123
  • 144
  • 2
    +1, cool, a non-issue then if that's the case. Was just annoyed at the thought of making a full copy when needing to add just a few k->v to the original map – virtualeyes Apr 13 '12 at 13:35
  • it would be interesting to expound on which immutable collections are more robust with additions and which ones aren't. I expect ListMaps to be one that wouldn't be very robust. – Andrew Norman Feb 17 '17 at 18:46
14

Using a mutable object is not bad in itself, it becomes bad in a functional programming environment, where you try to avoid side-effects by keeping functions pure and objects immutable.

However, if you create a mutable object inside a function and modify this object, the function is still pure if you don't release a reference to this object outside the function. It is acceptable to have code like:

def buildVector( x: Double, y: Double, z: Double ): Vector[Double] = {
    val ary = Array.ofDim[Double]( 3 )
    ary( 0 ) = x
    ary( 1 ) = y
    ary( 2 ) = z
    ary.toVector
}

Now, I think this approach is useful/recommended in two cases: (1) Performance, if creating and modifying an immutable object is a bottleneck of your whole application; (2) Code readability, because sometimes it's easier to modify a complex object in place (rather than resorting to lenses, zippers, etc.)

paradigmatic
  • 40,153
  • 18
  • 88
  • 147
  • Yes, the alternative to staying with immutable default was passing in a mutable map, then converting to immutable map prior to making the api call, so not functionally pure compared to your do-it-all-locally approach. It sounds like for the general, non-extreme case, immutable default is fine. Of course, I am still unclear as to concrete use cases for mutable map over immutable. Should have left the door open by not providing the trivial case that caused me to ask the question... – virtualeyes Apr 13 '12 at 15:12
  • +1: This is basically the "builder" pattern as employed by Microsoft's BCL immutable collections (https://www.nuget.org/packages/Microsoft.Bcl.Immutable) for .NET. – Richard Cook May 19 '14 at 14:54
6

In addition to dhg's answer, you can take a look to the performance of the scala collections. If an add/remove operation doesn't take a linear time, it must do something else than just simply copying the entire structure. (Note that the converse is not true: it's not beacuase it takes linear time that your copying the whole structure)

Nicolas
  • 24,509
  • 5
  • 60
  • 66
  • +1, excellent link, thanks. According to Performance & Characteristics, an add operation on immutable HashMap takes near constant time, which, in the current case, is just what I wanted to hear ;-) – virtualeyes Apr 13 '12 at 15:06
0

I like to use collections.maps as the declared parameter types (input or return values) rather than mutable or immutable maps. The Collections maps are immutable interfaces that work for both types of implementations. A consumer method using a map really doesn't need to know about a map implementation or how it was constructed. (It's really none of its business anyway).

If you go with the approach of hiding a map's particular construction (be it mutable or immutable) from the consumers who use it then you're still getting an essentially immutable map downstream. And by using collection.Map as an immutable interface you completely remove all the ".toMap" inefficiency that you would have with consumers written to use immutable.Map typed objects. Having to convert a completely constructed map into another one simply to comply to an interface not supported by the first one really is absolutely unnecessary overhead when you think about it.

I suspect in a few years from now we'll look back at the three separate sets of interfaces (mutable maps, immutable maps, and collections maps) and realize that 99% of the time only 2 are really needed (mutable and collections) and that using the (unfortunately) default immutable map interface really adds a lot of unnecessary overhead for the "Scalable Language".

Andrew Norman
  • 843
  • 9
  • 22