не ArrayList?

# russian

[m]

не ArrayList?

[gildor]

ArrayList это просто одна из имплементаций.
Со стороны JVM нет разницы между List и MutableList, все в итоге в байткоде будет java.util.List

[m]

жаль.. спасибо за ответ

[gildor]

Почему жаль? Интерфейс листа в джаве всегда имеет мутабельные методы.
И как я понимаю runtime эксепшн должен быть, даже после каста к MutableList, так как ImmutableList кидает UnsupportedOperationException если вызвать add/remove/etc, просто если использовать котлиновский интерфейс List, то там этих методов не будет при этом ImmutableList не позволит поменять контент листа даже если его передать в Java или явно кастонуть к MutableList

[m]

Жаль что компиляция возможна. Runtime ошибка меня не устраивает

[gildor]

В Java тоже runtime ошибка

[gildor]

Kotlin хотя бы позволяет спрятать методы, которые эту рантайм ошибку вызывают через интерфейс kotlin.collections.List который не имеет методов изменяющих контент

[m]

Да , но в java можно сконфигурировать lint падать если используются deprecated methods как ImmutableList.add

[m]

Плюс в java не возможно кастить его в ArrayList

[gildor]

но ведь lint не спасает от ошибок если передать immutable в метод который принимает просто java.util.List, довольно легко потерять тип (и это распространненая практика, возвращать наиболее абстрактный класс) и использовать ImmutableList как обычный List, причем случайно

[gildor]

Ну и в Kotlin его невозможно кастить в ArrayList

[gildor]

А в Java можно даже не кастить

[m]

Так в Java просто можно в подконтрольном коде не декларировать метод с List параметрами а декларировать как ImmutableList

[gildor]

В Kotlin в кодконтрольном коде можно использовать kotlin.collections.List

[gildor]

Впрочем как и ImmutableList

[m]

Ну так в Коtlin же возможна успешная конвертация его в ModifableList

[gildor]

Но ведь и в Java возможен его каст в List, это совершенно таже ситуация

[gildor]

MutableList это тоже самое что интерфейс List в Java

[gildor]

я просто не вижу никакой разницы с Java, разве что да, статические анализаторы могут отловить определенный процент подобным ошибок, вроде явного вызова метода, бросающего exception

[gildor]

Кстати это можно сделать и в Kotlin без проблем, достаточно включить Warnings as Error
http://kotlinlang.org/docs/reference/whatsnew12.html#warnings-as-errors

[gildor]

точно так же Kotlin будет ругаться на использование Deprecated метода и падать при билде в случае включения данной опции

[m]

Так в Java ето работает и так

[gildor]

А в Java это разве можно сделать?

[gildor]

нет, я не думаю что такой способ есть и не вижу как это можно реализовать, потому что сам по себе интерфейс java.util.List имеет методы add/remove

[m]

Ну вот. Жаль

[gildor]

т.е. есть огромное число совершенно валидных ситуаций, когда тип приводится к List и все, тут никакие провверки не помогут

[gildor]

Единственное радикальное решение, которое исправляет исторчник проблемы (java.util.List) это полностью отказаться от стандартных Java листов и сделать свою имплементацию и иерархию интерфейсов, но придется везде конвертировать из листа и в лист, что бы использовать с существующим кодом

[gildor]

мне кажется ситуация, когда кто-то закастил kotlin.collections.List к MutableList и получил при использовании add за это в ответ UnsupportedOperationException совершенно валидной, можно и несовместимые типы закастить и получить ClassCastException

[m]

Да. Ето понятно. Но мне нравится guava)

[gildor]

У гуавы ведь та же самая проблема, они имплементят java.util.List

[gildor]

Ну т.е. не проблема гуавы конечно)

[m]

Да, но я в подконтрольном коде использую только колекции guava

[gildor]

все же мне кажется kotlin.collection.List более чистым решением, по крайней мере для своего Kotlin кода, по крайней мере методы просто не доступны, а не deprecated

[gildor]

Но в случае смешаной кодовой базы с Java наверное ImmutableList все же более безопасное решение

[gildor]

Кстати есть еще такой прототип от JB:
https://github.com/Kotlin/kotlinx.collections.immutable

[m]

Спасибо.. А известно когда релиз?

[gildor]

Не знаю, думаю можно спросить @ilya.gorbunov так как он автор KEEP - https://github.com/Kotlin/KEEP/blob/master/proposals/stdlib/abstract-collections.md

[ilya.gorbunov]

Про релиз могу подсказать, что пока еще не скоро, т.к. есть нерешенные проблемы в API и нет достаточно хорошей имплементации.

[ilya.gorbunov]

Напомните, какие проблемы вы хотите решить использованием ImmutableList?

[m]

Ммм.. Хочу иметь гарантию что содержимое экземпляра класса ImmutableList невозможно будет удалять/добавлять/заменять никаким образом (рефлексия не в счет). То есть, например, ни после safe cast в MuttableList, ни после unsafe cast в MuttableList (как это сейчас с guava).

[ilya.gorbunov]

Возможно тогда хватит обертки над списком, сделанной с помощью java.util.Collections.unmodifiableList

[m]

а, тогда дополнительное условие: хочу чтоб либо (1) в классе ImmutableList методьі add, delete и т.д. бьіли deprecated (как в guava) чтобьі можно бьіло сконфигурировать lint падать если он заметит использование deprecated методов, либо (2) в классе ImmutableList методьі add, delete и т.д. отсуствовали. Вариант 2 предочтительнее

[m]

А, и это хотелки на все Immutable колекции, не только ImmutableList.

[m]

.. То есть эти Immutable колекции не должно бьіть возможньім кастить к Muttable колекции..

[gildor]

Если вы уже используете ImmutableList из Guava то Collections.unmodifiableList уже точно не нужен

в классе ImmutableList методьі add, delete и т.д. бьіли deprecated

Для этого придется использовать этот класс напрямую везде в коде вместо интерфейса. И все равно есть множество случаев где тип потеряется при передаче в метод к примеру.

ImmutableList методьі add, delete и т.д. отсуствовали

Их там просто не будет на стороне Kotlin, точно так же как и сейчас, т.к. интерфейс kotlin.collection.List не имеет методов модификациию И они точно будут на стороне Java. И эту проблему не решить без своей кастомной иерархии интерфейсов коллекций

сконфигурировать lint падать если он заметит использование deprecated методов

Это уже возможно с помощью флагов Kotlin компилятора

не должно бьіть возможньім кастить к Muttable колекции

Запретить кастить вы не можете, вы и сейчас что в Java, что в Kotlin можете написать "" as Int, тут только падать на ворнингах поможет и то не всегда. И вообще запретить кастить даже без ворнинга не получится, просто по причине того, что Mutable интерфейс наверняка будет наследников Immutable интерфейса (как это сейчас и работает в Kotlin) иначе очень его не удобно использовать.
И kotlinx.collections.immutable эту проблему вам не решат, так же как она не решается через Guava что на стороне Kotlin, что на стороне Java.

Но если честно я не вижу большой проблемы совсем, если кто-то пишет код который кастит без проверки типа и затем пытается поменять внутреннее состояние объекта то это его проблема, такой код плох сам по себе.
kotlin.collections.List решает большинство случаев со случайной модификацией, но если хочется серьезной защиты от модификации, то просто можно обернуть в Collections.unmodifiableList или использовать Guava ImmutableList как основу для коллекции и в дальнейшем использовать интерфейс kotlin.collections.List

[m]

Для этого придется использовать этот класс напрямую везде в коде вместо интерфейса.

Да, я так и делаю. Для этого это и нужно.

[m]

Если вы уже используете ImmutableList из Guava то Collections.unmodifiableList уже точно не нужен

Дело в том что ImmutableList из Guava в Kotlin возможно кастить в MutableList - это и делает бесполезньім использования ImmutableList из Guava в Kotlin.

[gildor]

Нет, это не так

[gildor]

Вы в java можете тоже кастить ImmutableList в List, но это не дает возможности менять содержимое

[gildor]

Точно так же и котлин, вы можете скастить, но поменять содержимое не получится

[gildor]

ImmutableList защищает лист от модификации, не важно к какому из родительских интерфейсов он прикасчен

[m]

да но в java я не могу кастить List o1 = (ArrayList) ImmutableList.of(); - не позволит компилятор

[gildor]

Ну так вы и в Котлине не можете это сделать

[m]

с guava ImmutableList могу

[gildor]

Зато в Java можете List o1 = ImmutableList.of();

[gildor]

Нет, если вы попытаетесь прикастить к ArrayList, то получите ClassCastException

[m]

Я имел ввиду что в Kotlin я могу c guava ImmutableList сделать так val mutableIList = ImmutableList.of(1,2) as MutableList<Int>

[m]

Так вот, я и хочу чтобьі в Kotlin бьіли Immutable колекции которьіе в частности нельзя кастить в Mutable колекции

[gildor]

Вы можете скастить, но это не даст клиенты модифицировать лист

[gildor]

mutableIList.add(3) //UnsopportedOperationException

[m]

Mutable интерфейс наверняка будет наследников Immutable интерфейса (как это сейчас и работает в Kotlin) иначе очень его не удобно использовать.

жаль(

[gildor]

Вы только что написали 100% аналог Java кода:
mutableIList = (List) ImmutableList.of(1,2)

[m]

Да, но мьі же хотим сделать Kotlin лучше java

[gildor]

Просто вы пишете, что Java каким то образом защищает вас от такого поведения, я же говорю что нет, поведение идентичное

[gildor]

жаль(

Вы всегда можете сделать свою иерархию классов с полностью кастомными интерфейсами которые делегируют имплементацию в ту же Guava и попробовать с ней поработать, это просто очень неудобно иметь 2 несовместимых интерфейса коллекций (нельзя просто взять и передать мутабельную коллекцию в метод который требует иммутабельный) которые постоянно приходится конвертировать еще и в платформенный java.util.List

[m]

В Java просто уже существует много всяких статических анализаторов которьіе можно настроить падать при компиляции

[gildor]

Какой статический анализатор будет ругаться на это?

mutableIList = (List) ImmutableList.of(1,2)

или на это:

void mutateList(List list) { … }

mutateList(ImmutableList.of(1,2))

[m]

error-prone (хотя не уверен)

[gildor]

Я совсем не уверен, так как абсолютно валидный кейс

[gildor]

особенно если mutableIList еще глубже передается

[m]

Хорошо, возможно в Java и нет таких анализаторв..

[gildor]

Конечно, хочется сделать Котлин лучше, но всегда есть ограничения просто логические и практического плана, если был бы какой то способ это решить то его можно было применить

[m]

Но будущая возможость в Kotlin кастить в Immutable в Mutable это как-то странно наверное..

[gildor]

но лечение (полностью несовместимые интерфейсы мутабильных и иммутабельных коллекций, не совместимые с java.util.List) хуже болезни (программист может явно прикастить к мутабельному типы, вызвать метод add/remove и получить UnsupportedOperationException)

[m]

это да..

[gildor]

Это не возможность Kotlin, это то, как работают интерфейсы на JVM и много где еще

[m]

хорошо, понятно

[m]

но может бьіть тогда хотя бьі компилятор Kotlin будет предупреждать о кастинге в Immutable в Mutable ?

[gildor]

Он и будет предупреждать на стороне Котлин о том что “This cast can never succeed” и падать с ClassCastException

[gildor]

но! Если вы его прикастите к List, который на стороне Java превратится в java.lang.List

[gildor]

т.е. на стороне Kotlin все работает, но при использовании на стороне Java нет

[m]

Эх..

[gildor]

и кстати тут вы правы, ImmutableList из kotlinx.immutable.collections спасет от проблемы с кастом, но опять же, только на стороне Kotlin:
https://try.kotlinlang.org/#/UserProjects/esb1haphvlhi3d0jasdbj5adh9/n6lb53kucglob8ofpnu4s7rie7