Generics – Out, In

Generics feature is template kind of implementation approach, which allow us to define classes, methods and properties which are accessible using different data types and keep a check of the compile-time type safety.

A generic type is a class or function that is parameterized over types. We always use angle brackets (<>) to specify the type parameter in the program.

Pros:

Compile time safety: Generics code is checked at compile time for the parameterized type so that it avoids run time error

Type casting: No need to typecast the object.

Type safety: Generic allows only single type of object at a time.

If you ever defined generic in Kotlin, you’ll notice many a times, it would propose to use the in or out keyword to define the generic. It puzzles me at a start on when which is used, and for what.

Formally, this is a way to define Covariant & Contravariance. Let’s see with the example in simple Word Processing and its implementation on Consumer (User) & Producer (Output Mode).

Out (Covariant):  If your generic class/interface only use the generic type as output of its function/s, it won't allow us to add the setter function with T

interface ProduceOutput<out T> {
    fun getContent(): T
}

This ProduceOutput interface, as it is mainly to produce output of the generic type. 

Side Note: produce = output = out

In (Contravariance): If your generic class/interface only use the generic type as input of its function/s, it won't allow us to getter function with T

interface ConsumeInput<in T> {
    fun consumeContent(data: T)
}

This ConsumeInput interface, as it is mainly to consuming the generic type. 

Side Note: consume = input = in

Before we see how the implementation on Producer and Consumer, lets create a necessary class hierarchy, which is going to handle the publishing industry on their document processing with their consumer base.

open class WordProcessor(val content: String, val isStyle: Boolean = false, val isAnimated: Boolean = false) {
    fun show() {
        println("Type : $content | Style: $isStyle | Animation: $isAnimated")
    }

    fun showConsumer() {
        println("Input : $content | Style: $isStyle | Animation: $isAnimated")
    }
}

open class Notes(input: String) : WordProcessor(input)
class Transcript(input: String) : Notes(input)
class FormattedNote(input: String) : WordProcessor(input, true)
class DigitalContent(input: String) : WordProcessor(input, true, true)

Implementation classes for producing the output via software tools as below

class GeneralProcessing : ProduceOutput<WordProcessor> {
    override fun getContent(): WordProcessor {
        return WordProcessor("Content Processor General")
    }
}

class Notepad : ProduceOutput<Notes> {
    override fun getContent(): Notes {
        return Notes("Notepad Content")
    }
}

class MSWord : ProduceOutput<FormattedNote> {
    override fun getContent(): FormattedNote {
        return FormattedNote("Formatted Content")
    }
}

class Flash : ProduceOutput<DigitalContent> {
    override fun getContent(): DigitalContent {
        return DigitalContent("Graphic Content")
    }
}

class SubEditPlayer : ProduceOutput<Transcript> {
    override fun getContent(): Transcript {
        return Transcript("Subtitle Content")
    }
}

For 'out' generic, we could assign a class of subtype to class of super-type, Please check out the comments in the code.

/*out -- This subtype class will be assigned only to the same type or super type class*/
    
val meetingMinutes: ProduceOutput<WordProcessor> = Notepad()
val wallPoster: ProduceOutput<WordProcessor> = MSWord()
val flashGame: ProduceOutput<WordProcessor> = Flash()
val osDefaultDoc: ProduceOutput<WordProcessor> = GeneralProcessing()
val youtubeSubtitle: ProduceOutput<Transcript> = SubEditPlayer()

// Eg: out compiler error
// val meetingRecording:ProduceOutput<DigitalContent> = GeneralProcessing() // Error
// val poster:ProduceOutput<Notepad> = GeneralProcessing() //Error
val twoDGame: ProduceOutput<DigitalContent> = Flash() // This works - Same Class Type
val subTile: ProduceOutput<WordProcessor> = SubEditPlayer() // This works --  subtype assigned to supertype

meetingMinutes.getContent().show()
wallPoster.getContent().show()
flashGame.getContent().show()
osDefaultDoc.getContent().show()
youtubeSubtitle.getContent().show()
twoDGame.getContent().show()
subTile.getContent().show()

Implementation classes of the users who consumes i.e. prepare or use these tools

class GeneralReviewer : ConsumeInput<WordProcessor> {
    override fun consumeContent(data: WordProcessor) {
        println("GeneralReviewer -- Review the content")
        data.showConsumer()
    }
}

class Reporter : ConsumeInput<Notes> {
    override fun consumeContent(data: Notes) {
        println("Reporter - Taken Rough Notes")
        data.showConsumer()
    }
}

class ContentDesigner : ConsumeInput<FormattedNote> {
    override fun consumeContent(data: FormattedNote) {
        println("Designer - Formatted the content")
        data.showConsumer()
    }
}

class GraphicDesigner : ConsumeInput<DigitalContent> {
    override fun consumeContent(data: DigitalContent) {
        println("Graphic Designer -- Added Animation Effects to the content")
        data.showConsumer()
    }
}

class SubtitleWriter : ConsumeInput<Transcript> {
    override fun consumeContent(data: Transcript) {
        println("Subtitle Writer -- Updated subtitle content")
        data.showConsumer()
    }
}

For ‘in' generic, we could assign a class of super-type to class of subtype, Please check out the comments in the code.

/*in -- This supertype class will be assigned only to the same type or subtype class*/

val takeNotes: ConsumeInput<Notes> = Reporter()
val pageMaker: ConsumeInput<FormattedNote> = ContentDesigner()
val adFilm: ConsumeInput<DigitalContent> = GraphicDesigner()
val generalContent: ConsumeInput<WordProcessor> = GeneralReviewer()
val subTag: ConsumeInput<Transcript> = SubtitleWriter()

// Eg: in compiler error
// val takeNotes2: ConsumeInput<WordProcessor> = Reporter() // Error
// val pageMaker2: ConsumeInput<WordProcessor> = ContentDesigner() // Error
// val adFilm2: ConsumeInput<WordProcessor> = GraphicDesigner() // Error
// val tagline: ConsumeInput<WordProcessor> = SubtitleWriter() // Error
val generalContent2: ConsumeInput<WordProcessor> = GeneralReviewer() // No Error Same Type
val subTag2: ConsumeInput<Transcript> = GeneralReviewer() // No Error -- supertype assigned to subtype

takeNotes.consumeContent(Notes("Hello, Welcome to meeting"))
pageMaker.consumeContent(FormattedNote("Thank you all"))
adFilm.consumeContent(DigitalContent("BGM Rocks"))
generalContent.consumeContent(WordProcessor("Great to review"))
generalContent2.consumeContent(WordProcessor("GeneralContent2: Great to review"))
subTag.consumeContent(Transcript("Display at the bottom"))
subTag2.consumeContent(Transcript("Subtag 2: Display at the bottom"))

Very simple way to remember In and Out to be used on the implementation.  Also, importantly if anything we do mistakes, it will stop us at the compile time itself.  

Use IN => Super Type could be assigned subtype

Use OUT => Sub Type could be assigned to Super Type

Value Class Kotlin

Value class adds attribute to a value and constraint it’s usage. This class is nothing but a wrapper around a value, but the Kotlin compiler makes sure there is no overhead due to wrapping.

Classes in Kotlin solve two problems:

1. They convey meaning through their name and make it easier for us to understand what kind of object is passed along.
2. They enforce type-safety by making sure that an object of class A cannot be passed to a function that expects an object of class B as an input parameter. This prevents serious bugs at compile-time.

Primitive: ❌

Primitive types like Int, Boolean, String or Double also enforce type-safety (you can’t just pass a String where a Boolean is expected), but they don’t really convey a meaning (other than an object being a number of a certain format, for example).

A Double could be pretty much anything: a temperature in degrees Celsius, a weight in kilograms, or your screen’s brightness level in percent. All we know is that we’re dealing with a floating-point number with double precision (64 bits), but it doesn’t tell us what this number represents. For that reason, the semantic type-safety is lost.

Assume below example, there is a function we are about to pass two String param (username and password).

fun getAuthToken(username:String, password:String) {
....
}

see to the above function we are able to pass the param like this and which is wrong doesn't care at the compiler level. (even we have named params both accepts the String), Hence here primitives fails.

val uname = "juno ravi"
val pwd = "P@ssw0rd!123"

val token = getAuthToken(pwd, uname) 

This programming error cannot be detected at compile-time and will most likely lead to unexpected behavior. 💥

There are different approaches to solving the two problems mentioned above. We could just wrap a primitive type in a class, but that comes with a lot of overhead. So let’s see how we can tackle these problems above with

• data classes, 😈
• type aliases,  😜
• and value classes 😎

Data classes: Instantiating data classes is expensive. Primitive values can be written to the stack which is fast and efficient. Instances of data classes are written to the heap, which takes more time and memory.

data class Username(val username: String)
data class Password(val password: String)

fun getAuthToken(username:Username, password:Password) {
....
}

with the above implementation is able to achieve but it is too costly process, comparatively if primitive took 2.x milliseconds means, it will take 8.x milliseconds for the single process.  Hence it is not advisable to do 😈

Type aliases: From the below Example, String & Username and Password are synonyms.

Whenever the compiler sees Username/Password, it basically replaces it with String and moves on.

typealias Username = String

typealias Password = String

Since our new Username/Password type alias is now equal to String, hence it works as same as primitvies which we have seen above, it also receives the same optimization treatment as Primitive but loses the typesafety. 😜

Value classes: It looks pretty similar to data classes. The signature looks exactly the same, except that instead of data class the keyword is value class, also there should be @JvmInline annotation to that class due to the Valhalla JVM release in future (currently JVM supports value class on the built in primitive types).  Important thing is the value class accepts only one constructor param.  

Since this value class acts as a wrapper to that variable, it also receives the same optimization treatment as Primitive which we can see it on the below screenshot on the highlighted section of the Kotlin byte code where as uname is referred it as Username class type, but pwd is referred as String value type, because it is defined with a value class 😎

Side Note: 

Since Kotlin 1.2.xx, we have inline classes, the old name for the value class. Since the class is not actually inlined in comparison to the inline function, it has been renamed to value class and the inline keyword is deprecated from Kotlin 1.5

Happy Coding :-)