abstract class Fruit(val ripeness: Double)Ĭlass Banana(ripeness: Double, val bendiness: Double):Ĭlass Peach(ripeness: Double, val fuzziness: Double): If you do specify a base class for a user-defined class, the base class will be the immediate supertype of the new class, but the ultimate ancestor of the class will be the type Any. If you define a class that is not explicitly derived from another class, the class will be an immediate subtype of Any. They are all part of the same type hierarchy. Unlike Java, Kotlin does not draw a distinction between “primitive” types, that are intrinsic to the language, and user-defined types. For example, the types String and Int are both subtypes of Any.Īny is the equivalent of Java’s Object class. Starting from the TopĪll types of Kotlin object are organised into a hierarchy of subtype/supertype relationships.Īt the “top” of that hierarchy is the abstract class Any. Thanks to those rules, Kotlin can provide useful, user extensible language features – null safety, polymorphism, and unreachable code analysis – without resorting to special cases and ad-hoc checks in the compiler and IDE. Those rules combine together consistently and predictably. Kotlin’s type hierarchy has very few rules to learn. That’s a shame, because I find it to be really neat 1. But I’ve not found an article that describes in one place how Kotlin’s type hierarchy fits together.
Kotlin has plenty of good language documentation and tutorials. A Whirlwind Tour of the Kotlin Type Hierarchy
0 kommentar(er)
