Чем дженерики в kotlin отличаются от джазовых

Обобщения (Generics): in, out, where

Как и в Java, в Kotlin классы могут иметь типовые параметры.

class Box(t: T)

Для того чтобы создать объект такого класса, необходимо предоставить тип в качестве аргумента.

val box: Box = Box(1) 

Но если параметры могут быть выведены из контекста (в аргументах конструктора или в некоторых других случаях), можно опустить указание типа.

val box = Box(1) // 1 имеет тип Int, поэтому компилятор отмечает для себя, что тип переменной box — Box

Вариативность

Одним из самых сложных мест в системе типов Java являются маски (ориг. wildcards) (см. Java Generics FAQ). А в Kotlin их нет. Вместо этого, в Kotlin есть вариативность на уровне объявления и проекции типов.

` is _not_ a subtype of `List `. If `List` were not _invariant_, it would have been no better than Java’s arrays, as the following code would have compiled but caused an exception at runtime: —>

Давайте подумаем, зачем Java нужны эти загадочные маски. Проблема хорошо описана в книге Effective Java, Item 28: Use bounded wildcards to increase API flexibility. Прежде всего, обобщённые типы в Java являются инвариантными (ориг. invariant). Это означает, что List не является подтипом List . Если бы List был изменяемым, он был бы ничем не лучше массива в Java, потому что после компиляции данный код вызвал бы ошибку во время выполнения.

// Java List strs = new ArrayList(); List objs = strs; // . Причина вышеуказанной проблемы заключена здесь, Java запрещает так делать objs.add(1); // Тут мы помещаем Integer в список String'ов String s = strs.get(0); // . ClassCastException: не можем кастовать Integer к String 

Java запрещает подобные вещи, гарантируя тем самым безопасность выполнения кода. Но у такого подхода есть свои последствия. Рассмотрим, например, метод addAll() интерфейса Collection . Какова сигнатура данного метода? Интуитивно мы бы указали её таким образом:

// Java interface Collection . < void addAll(Collectionitems); > 

Но тогда мы бы не могли выполнять следующую простую операцию (которая является абсолютно безопасной):

// Java void copyAll(Collection to, Collection from) < to.addAll(from); // . Не скомпилируется с наивным объявлением метода addAll: // Collectionне является подтипом Collection > 

(В Java вы, вероятно, познали это на своём горьком опыте, см. Effective Java, Item 25: Prefer lists to arrays)

Вот почему сигнатура addAll() на самом деле такая:

// Java interface Collection . < void addAll(Collectionitems); > 

` _is_ a subtype of `Collection `. In other words, the wildcard with an _extends_\-bound (_upper_ bound) makes the type _covariant_. —>

Маска для аргумента ? extends E указывает на то, что этот метод принимает коллекцию объектов E или некоего типа унаследованного от E , а не только сам E . Это значит, что вы можете безопасно читать объекты типа E из содержимого (элементы коллекции являются экземплярами подкласса E), но не можете их присваивать, потому что не знаете, какие объекты соответствуют этому неизвестному подтипу E . Минуя это ограничение, желаемый результат может быть достигнут: Collection является подтипом Collection . Другими словами, маска с extends-связкой (верхнее связывание) делает тип ковариантным (ориг. covariant).

`, a _supertype_ of `List `. —>

Ключом к пониманию, почему этот трюк работает, является довольно простая мысль: использование коллекции String ‘ов и чтение из неё Object нормально только в случае, если вы только берёте элементы из коллекции. Наоборот, если вы только вносите элементы в коллекцию, то нормально брать коллекцию Object ‘ов и помещать в неё String ‘и: в Java есть List , супертип List .

` (for example, you can call `add(String)` or `set(int, String)`). If you call something that returns `T` in `List `, you don’t get a `String`, but rather an `Object`. —>

Это называется контрвариантностью (ориг.: contravariance). Вы можете вызвать только те методы, которые принимают String в качестве аргумента в List (например, вы можете вызвать add(String) или set(int, String) ). В случае, если вы вызываете из List что-то с возвращаемым значением T , вы получаете не String , а Object .

Джошуа Блох (Joshua Bloch) называет объекты:

• Производителями (ориг.: producers), если вы только читаете из них,
• Потребителями (ориг.: consumers), если вы только записываете в них.

«For maximum flexibility, use wildcard types on input parameters that represent producers or consumers», > and proposes the following mnemonic: > >_PECS stands for Producer-Extends, Consumer-Super._ —>

Для максимальной гибкости используйте маски на входных параметрах, которые представляют производителей или потребителей, и предлагает следующую мнемонику:

PECS обозначает Producer-Extends, Consumer-Super.

If you use a producer-object, say, `List `, you are not allowed to call `add()` or `set()` on this object, > but this does not mean that it is _immutable_: for example, nothing prevents you from calling `clear()` > to remove all the items from the list, since `clear()` does not take any parameters at all. > >The only thing guaranteed by wildcards (or other types of variance) is _type safety_. Immutability is a completely different story. —>

Если вы используете объект-производитель, предположим, List , вы не можете вызвать методы add() или set() этого объекта. Но это не значит, что объект является неизменяемым: например, ничто не мешает вам вызвать метод clear() для того, чтобы очистить список, так как clear() не имеет аргументов.

Единственное, что гарантируют маски (или другие типы вариантности) — безопасность типов. Неизменяемость — совершенно другая история.

Вариантность на уровне объявления

` that does not have any methods that take `T` as a parameter, only methods that return `T`: —>

Допустим, у вас есть обобщённый интерфейс Source , у которого нет методов, принимающих T в качестве аргумента. Только методы, возвращающие T :

// Java interface Source

` in a variable of type `Source ` — there are no consumer-methods to call. But Java does not know this, and still prohibits it: —>

Тогда было бы вполне безопасно хранить ссылки на экземпляр Source в переменной типа Source — не нужно вызывать никакие методы-потребители. Но Java не знает этого и не воспринимает такой код.

// Java void demo(Source strs) < Sourceobjects = strs; // . Запрещено в Java // . > 

`. Doing so is meaningless, because you can call all the same methods on such a variable as before, so there’s no value added by the more complex type. But the compiler does not know that. —>

Чтобы исправить это, вам нужно объявить объекты типа Source , что в каком-то роде бессмысленно, потому что у переменной такого типа вы можете вызывать только те методы, что и ранее, стало быть, более сложный тип не добавляет смысла. Но компилятор этого не понимает.

`, and never consumed. To do this, use the `out` modifier: —>

В Kotlin существует способ объяснить вещь такого рода компилятору. Он называется вариантность на уровне объявления: вы можете объявить типовой параметр T класса Source таким образом, чтобы удостовериться, что он только возвращается (производится) членами Source , и никогда не потребляется. Чтобы сделать это, вам необходимо использовать модификатор out .

interface Source  < fun nextT(): T >fun demo(strs: Source) < val objects: Source= strs // Всё в порядке, т.к. T — out-параметр // . > 

` can safely be a supertype of `C `. —>

Общее правило таково: когда параметр T класса С объявлен как out , он может использоваться только в out-местах в членах C . Но зато C может быть родителем C , и это будет безопасно.

Другими словами, класс C ковариантен в параметре T ; или T является ковариантным типовым параметром. C производит экземпляры типа T , но не потребляет их.

Модификатор out определяет вариантность, и так как он указывается на месте объявления типового параметра, речь идёт о вариативности на месте объявления. Эта концепция противопоставлена вариативности на месте использования из Java, где маски при использовании типа делают типы ковариантными.

В дополнении к out , Kotlin предоставляет дополнительный модификатор in . Он делает параметризованный тип контравариантным: он может только потребляться, но не может производиться. Comparable является хорошим примером такого класса:

interface Comparable  < operator fun compareTo(other: T): Int >fun demo(x: Comparable) < x.compareTo(1.0) // 1.0 имеет тип Double, расширяющий Number // Таким образом, мы можем присвоить значение x переменной типа Comparableval y: Comparable = x // OK! > 

Слова in и out говорят сами за себя (так как они довольно успешно используются в C# уже долгое время), таким образом, мнемоника, приведённая выше, не так уж и нужна, и её можно перефразировать следующим образом:

Экзистенциальная Трансформация: Consumer in, Producer out! 🙂

Проекции типов

Вариативность на месте использования

Объявлять параметризованный тип T как out очень удобно: при его использовании не будет никаких проблем с подтипами. И это действительно так в случае с классами, которые могут быть ограничены на только возвращение T . А как быть с теми классами, которые ещё и принимают T ? Хороший пример этого: класс Array :

class Array(val size: Int) < operator fun get(index: Int): T < . >operator fun set(index: Int, value: T) < . >> 

Этот класс не может быть ни ко-, ни контравариантным по T , что ведёт к некоторому снижению гибкости. Рассмотрим следующую функцию:

fun copy(from: Array, to: Array)

По задумке, это функция должна копировать значения из одного массива в другой. Давайте попробуем сделать это на практике:

val ints: Array = arrayOf(1, 2, 3) val any = Array(3) < "" >copy(ints, any) // ^ Ошибка: тип Array, а ожидалось Array

` is _invariant_ in `T`, and so neither `Array ` nor `Array ` is a subtype of the other. Why not? Again, this is because `copy` could have an unexpected behavior, for example, it may attempt to write a `String` to `from`, and if you actually pass an array of `Int` there, a `ClassCastException` will be thrown later. —>

Здесь вы встречаете уже знакомую вам проблему: Array инвариантен по T , таким образом Array не является подтипом Array . Почему? Опять же, потому что копирование потенциально опасно, например может произойти попытка записать, скажем, значение типа String в from . И если мы на самом деле передадим туда массив Int , будет выброшен ClassCastException .

Чтобы запретить функции copy записывать в from , вы можете сделать следующее:

fun copy(from: Array, to: Array)

` while being slightly simpler. —>

Произошедшее здесь называется проекция типов: мы сказали, что from — не просто массив, а ограниченный (спроецированный): мы можем вызывать только те методы, которые возвращают параметризованный тип T , что в этом случае означает, что мы можем вызывать только get() . Таков наш подход к вариативности на месте использования, и он соответствует Array из Java, но в более простом виде.

Вы также можете проецировать тип с помощью in .

fun fill(dest: Array, value: String)

` corresponds to Java’s `Array `. This means that you can pass an array of `CharSequence` or an array of `Object` to the `fill()` function. —>

Array соответствует Array из Java, то есть мы можем передать массив CharSequence или массив Object в функцию fill() .

«Звёздные» проекции

Иногда возникает ситуация, когда вы ничего не знаете о типе аргумента, но всё равно хотите использовать его безопасным образом. Этой безопасности можно добиться путём определения такой проекции параметризованного типа, при которой его экземпляр будет подтипом этой проекции.

Для этого в Kotlin есть так называемый синтаксис star-projection:

• Для Foo , где T — ковариантный параметризованный тип с верхней границей TUpper , Foo является эквивалентом Foo . Это значит, что когда T неизвестен, вы можете безопасно читать значения типа TUpper из Foo ;
• Для Foo , где T — контравариантный параметризованный тип, Foo является эквивалентом Foo . Это значит, что вы не можете безопасно писать в Foo при неизвестном T ;
• Для Foo , где T — инвариантный параметризованный тип с верхней границей TUpper , Foo является эквивалентом Foo при чтении значений и Foo при записи значений.

Если параметризованный тип имеет несколько параметров, каждый из них проецируется независимо. Например, если тип объявлен как interface Function , вы можете представить следующую «звёздную» проекцию:

• Function означает Function ;
• Function означает Function ;
• Function означает Function .

«Звёздные» проекции очень похожи на сырые (raw) типы из Java, за тем исключением того, что они безопасны.

Обобщённые функции

Функции, как и классы, могут иметь типовые параметры. Типовые параметры помещаются перед именем функции.

fun singletonList(item: T): List  < // . >fun T.basicToString(): String < // функция-расширение // . >

Для вызова обобщённой функции, укажите тип аргументов на месте вызова после имени функции.

val l = singletonList(1) 

Аргументы типа можно опустить, если их можно вывести из контекста, поэтому следующий пример также работает:

val l = singletonList(1) 

Обобщённые ограничения

Набор всех возможных типов, которые могут быть переданы в качестве параметра, может быть ограничен с помощью обобщённых ограничений.

Верхние границы

Самый распространённый тип ограничений — верхняя граница, которая соответствует ключевому слову extends из Java.

fun > sort(list: List)

` can be substituted for `T`. For example: —>

Тип, указанный после двоеточия, является верхней границей: только подтип Comparable может быть передан в T . Например:

sort(listOf(1, 2, 3)) // Всё в порядке. Int — подтип Comparable sort(listOf(HashMap())) // Ошибка: HashMap не является подтипом Comparable 

По умолчанию (если не указана явно) верхняя граница — Any? . В угловых скобках может быть указана только одна верхняя граница. Для указания нескольких верхних границ нужно использовать отдельное условие where .

fun copyWhenGreater(list: List, threshold: T): List where T : CharSequence, T : Comparable  < return list.filter < it >threshold >.map < it.toString() >> 

Переданный тип должен одновременно удовлетворять всем условиям where . В приведенном выше примере тип T должен реализовывать и CharSequence , и Comparable .

Удаление типа

` and `Foo ` are erased to just `Foo `. —>

Проверки безопасности типов, выполняемые Kotlin для использования общих объявлений, выполняются во время компиляции. Во время выполнения экземпляры общих типов не содержат никакой информации об их фактических аргументах типа. Говорят, информация о типе будет удалена. Например, экземпляры Foo и Foo удаляются до Foo .

Поэтому нет общего способа проверить, был ли создан экземпляр общего типа с определенными аргументами типа во время выполнения, и компилятор запрещает такие is -проверки.

`, cannot be checked at runtime. These [unchecked casts](typecasts.md#unchecked-casts) can be used when type safety is implied by high-level program logic but cannot be inferred directly by the compiler. The compiler issues a warning on unchecked casts, and at runtime, only the non-generic part is checked (equivalent to `foo as List `). —>

Приведение типов к обобщенным типам с конкретными аргументами типа, например foo as List , не может быть проверено во время выполнения. Эти непроверенные приведения могут использоваться, когда безопасность типов подразумевается программной логикой высокого уровня, но не может быть выведена непосредственно компилятором. Компилятор выдает предупреждение о непроверенных приведениях, и во время выполнения проверяется только необобщенная часть (эквивалентно foo as List ).

Типовые аргументы вызовов обобщенных функций также проверяются только во время компиляции. Внутри тел функций параметры типа нельзя использовать для проверки типов, а приведение типов к параметрам типа ( foo as T ) не проверено. Однако параметры вещественного типа встроенных функций заменяются фактическими аргументами типа в теле встроенной функции на стороне вызовов и поэтому могут использоваться для проверки и приведения типов с теми же ограничениями для экземпляров обобщенных типов, как описано выше.

© 2015—2023 Open Source Community

Difference between Any type and Generics in Kotlin

I guessed it should be valid. However, the IntelliJ IDEA linter shows a type mismatch error That being said, I would change the return type of my parse function to Any, right? So that, what is the difference between using Any type and Generics in Kotlin? In which cases should use each of those? I did read the following question but not understood at all about star-projection in Kotlin due to the fact I am quite new.

asked Oct 19, 2017 at 17:37
345 1 1 gold badge 8 8 silver badges 25 25 bronze badges
This Java answer might help you stackoverflow.com/questions/5207115/java-generics-t-vs-object
Oct 19, 2017 at 17:45
Did you find an answer?
Dec 1, 2017 at 7:23

3 Answers 3

Your return type it defined as T , but there is nothing assuring that T and a:Any are related. T may be more restrictive than Any , in which case you can’t return a boolean or whatever you provided for a .

The following will work, by changing the return type from T to Any :

fun parse(a: Any): Any = when (a) < is String ->a else -> false > 

Any alternate option, if you really want to return type T:

inline fun parse(a: Any): T? = when (a) < is T ->a else -> null > 

answered Oct 19, 2017 at 18:30
506 4 4 silver badges 12 12 bronze badges

Your example does not use T and thus it’s nonsense to make it generic anyways.

Think about this: As a client you put something into a function, e.g. an XML- ByteArray which the function is supposed to parse into an Object . Calling the function you do not want to have it return Any (Casting sucks) but want the function return the type of the parsed object. THIS can be achieved with generics:

fun parse(xml: ByteArray): T < val ctx: JAXBContext = JAXBContext.newInstance() val any = ctx.createUnmarshaller().unmarshal(ByteArrayInputStream(xml)) return any as T >val int = parse("123".toByteArray()) val string = parse("123".toByteArray()) 

Look at the method calls: You tell with generics what type is expected to be returned. The code is not useful and only supposed to give you an idea of generics.

answered Oct 19, 2017 at 18:47
77.6k 17 17 gold badges 168 168 silver badges 196 196 bronze badges

I guessed it should be valid

Why would it be? You return a String in one branch and a Boolean in the other. So the common type for the entire when expression is Any and that’s what the compiler (and IDEA) says is «found». Your code also says it should be T (which is «required»).

Your generic method should work for any T , e.g. for Int , but Any isn’t a subtype of Int and so the code isn’t valid.

So that, what is the difference between using Any type and Generics in Kotlin?

This is like asking «what is the difference between using numbers and files»: they don’t have much in common in the first place. You use generics to write code which can work with all types T (or with all types satisfying some constraint); you use Any when you want the specific type Any .

Generics: in, out, where

Classes in Kotlin can have type parameters, just like in Java:

class Box(t: T)

To create an instance of such a class, simply provide the type arguments:

val box: Box = Box(1)

But if the parameters can be inferred, for example, from the constructor arguments, you can omit the type arguments:

val box = Box(1) // 1 has type Int, so the compiler figures out that it is Box

Variance

One of the trickiest aspects of Java’s type system is the wildcard types (see Java Generics FAQ). Kotlin doesn’t have these. Instead, Kotlin has declaration-site variance and type projections.

Let’s think about why Java needs these mysterious wildcards. The problem is explained well in Effective Java, 3rd Edition, Item 31: Use bounded wildcards to increase API flexibility. First, generic types in Java are invariant, meaning that List is not a subtype of List . If List were not invariant, it would have been no better than Java’s arrays, as the following code would have compiled but caused an exception at runtime:

// Java List strs = new ArrayList(); List objs = strs; // . A compile-time error here saves us from a runtime exception later. objs.add(1); // Put an Integer into a list of Strings String s = strs.get(0); // . ClassCastException: Cannot cast Integer to String

Java prohibits such things in order to guarantee run-time safety. But this has implications. For example, consider the addAll() method from the Collection interface. What’s the signature of this method? Intuitively, you’d write it this way:

// Java interface Collection . < void addAll(Collectionitems); >

But then, you would not be able to do the following (which is perfectly safe):

// Java void copyAll(Collection