The kotlin type system is so simple

Quote

In the process of learning kotlin, I was curious about kotlin's type system. Does kotlin have a common base class similar to object in Java? Is there a separate branch in kotlin similar to the Java base type? After some research, bloggers found that kotlin gave a more satisfactory answer than Java, and was surprisingly simple. It only needs to follow simple rules to understand the whole type system.

Any

Any is equivalent to the concept of object in Java. Any wrote in the comment:

Let's simply verify that any is the base class of everything.

class Fruit
fun main(args: Array<String>) {
println(Fruit() is Any)
}

In the above code, we create a new class, and then construct its instance to see if it is any. The answer is obviously true.

We are looking at whether the parent classes of some basic types in kotlin, that is, int, double, float, byte, etc., are also any.

println(3.233F is Any)
println(2 is Any)

The answer is also true. As an additional explanation, kotlin does not handle the differentiation of basic types and encapsulation types in Java, nor does it handle unpacking and boxing. Base types are base types, but they also have any as their parent.

Unit

Let's take a look at unit, a special thing in kotlin.

/**
* The type with only one value: the `Unit` object.
* This type corresponds to the `void` type in Java.
*/
public object Unit {
override fun toString() = "kotlin.Unit"
}

The concept is explained here and will be mentioned again in subsequent chapters. Kotlin has done a lot of work for the concept that there must be a return value, but the benefits are very obvious. We can look at kotlin's functions from a unified perspective.

The concept of unit represents doing nothing, but doing nothing is indeed a return value. If we don't make any declaration, the return value of the function is unit, indicating that I returned something I didn't do anything.

Let's verify, declare an empty function, and then print it. (it will be compiled in Java)

fun justReturn() {
}

fun main(args: Array<String>) {
print(justReturn())
}

The result outputs kotlin. Unit, which proves that the return value is unit.

So here's a question: what's the relationship between unit and any? Let's take a look through the is keyword.

fun main(args: Array<String>) {
print(justReturn() is Any)
}

EN en, unit is also a subclass of any!

Nothing

We continue to extend the concept that each function in kotlin must have a return value. We looked at the normal return. Will there be a return value if there is an exception in the program? In this case, kotlin also continues the concept that there must be a return value. This return value is called - nothing!

Nothing means unreachable. When the program actually runs, it will not produce any object of type nothing. What?! How do you understand that. Once kotlin finds that nothing is returned, it will ensure that the following code will not be executed.

Therefore, nothing is often used in the case of abnormal exit such as throw, so that the subsequent code will not be executed. Let's look at the example of kotlin itself.

/**
* Terminates the currently running process.
*
* @param status serves as a status code; by convention,* a nonzero status code indicates abnormal termination.
*
* @return This method never returns normally.
*/
@kotlin.internal.InlineOnly
public inline fun exitProcess(status: Int): Nothing {
System.exit(status)
throw RuntimeException("System.exit returned normally,while it was supposed to halt JVM.")
}

Notice, let's look at the position of nothing in the type system. Nothing, contrary to any, is a subclass of all types! In other words, nothing is fruit, school, money and any. Nothing means an unreachable state. Each type contains this unreachable state, so nothing is a subclass of these.

Note the position of nothing in the figure above.

Nullable

One of kotlin's trumps is this nullable type, which is followed by?, This type can be empty. Let's look at the type system after the introduction of nullable types.

1. First, look at the relationship between ordinary classes and nullable types.

class Fruit
fun main(args: Array<String>) {
print(Fruit() is Fruit?)
}

The answer is true. It is easy to understand here. The difference between the two is whether they can be empty. Those that can be empty are naturally the base class, and those that cannot be empty are a derivation that can be empty.

2. Does any have a nullable type

The most admirable thing about kotlin is the implementation of a concept. Any also has nullable types in kotlin. Sensory any? Is the parent of any, and any is the parent of non nullable type, so any? Is it also a parent of a non nullable type? That's the answer. Let's verify it.

class Fruit
fun main(args: Array<String>) {
print(Fruit() is Any?)
}

3. Does unit have nullable type

Yes, unit also has an empty type unit?. But this is a difficult concept to understand. It itself contains two values, unit and null. This is kotlin's intention to continue the concept of unification. Few scenarios are used, but we should be clear.

4. Whether nothing has nullable type

Of course, nothing also has nullable type nothing?, It itself has and has only one value null, that is, it is null. Nothing itself is unreachable. There will be no instance, so it can only be null.

Let's verify it

fun main(args: Array<String>) {
println(null is Nothing)
println(null is Nothing?)
println(null is Any)
println(null is Any?)
}

They are false, true, false, and true.

summary

Let's borrow natpryce's diagram. Let's take a look at this diagram. This is kotlin's type system.

We only need to understand a few points to fully understand the kotlin type system.

When we don't know the type, we can understand it by comparing the above two concepts.

reference resources

summary

The above is the whole content of this article. I hope the content of this article has a certain reference value for your study or work. Thank you for your support.