idiomatic way of writing HashMap in kotlin

Question

Few days back i was reading an article about the Kotlin features. There one feature it told about using HashMap in more efficient way.

Old way of writing code in hashmap val map = HashMap<String, String>(). This doesn't give good readability about the what is the actual value it's going to keep.

Example if it keep Person name and his address in it. wouldn't be nice to have val map = HasMap<Name, Address> so by seeing the declaration it's more readable. I tried finding the article but i am not able get it. How can do i tried but not able to get the same.

Answer 1

You probably mean type aliases

inline classes are still experimental.

Answer 2

val map = mapOf(1 to "x", 2 to "y", -1 to "zz")

val mutableMap = mutableMapOf("name" to "Luke", "age" to "23") 

https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/map-of.html

https://www.deadcoderising.com/how-to-create-maps-in-kotlin-using-5-different-factory-functions-2/

Answer 3

Without seeing the article, it's hard to know, but one possibility might be encouraging basic object-oriented design (not specific to Kotlin or to maps).  For example:

data class Name(title: String, forename: String, surname: String)

data class Address(number: Int, street: String, city: String)

val map = mapOf(Name("Mr", "Fred", "Bloggs") to Address("10", "London Road", "London"),
                Name("Mrs", "Jane", "Smith") to Address("5", "The Larches", "Woodville"))

That makes most sense if your names and addresses have some internal structure that you want to represent.  (In practice, it's often safer not to, as there are many gotchas about names and addresses that are likely to break any assumptions you make about them!)  However, this could still work well for objects that contain only a single String property.

Advantages include:

• Readability.  As in the question, this makes explicit the meaning and intent of the keys and values.  (No need to put it in the variable name.)
• Type-safety.  The compiler checks the types, preventing you from storing a name in an address field by mistake.
• Isolation.  You can change the details of how names or addresses are represented, without needing to change all the code that uses them.
• You can give your objects behaviours where appropriate (e.g. calculated properties, serialisation, &c).
• You get access to the internal structure of the field, without any further processing or assumptions.

(Inline classes and type aliases, as per other answers, are variations on this: more efficient, but less flexible.)

Answer 4

This isn't at all specific to Map or HashMap but you can define type aliases

typealias Name = String
typealias Address = String

and then use them everywhere types are needed. Or for more type safety, inline classes because type aliases allow any String operation to be done on Address and vice versa.