AN
а ещё есть массивы примитивов...
Вот они идут отдельно. Но они и так отдельные классы, которые не наследуют массив.
Object[], реализующий List. Просто когда его делали, инлайн-классов ещё и в проекте не было)Size: a a a
2019 November 11
VP
ИМХО, Array<> нужен, но как инлайн-класс над
Интероп поплыл бы, там ведь не только Object[]
AN
Но в идеале я бы сказал, что компилятор тоже должен определять примитивы и подставлять DoubleArray вместо Array<Double>
VP
Но в идеале я бы сказал, что компилятор тоже должен определять примитивы и подставлять DoubleArray вместо Array<Double>
Так это не одно и то же. Абстрагировать это не получится.
QH
Интероп поплыл бы, там ведь не только Object[]
да, насратб, я вот и запилил себе инлайн-класс
Arr, у которого внутри стёртый массивAN
Так это не одно и то же. Абстрагировать это не получится.
Единственная проблема, по которой нельзя массив унаследовать от листа - это рефлексия.
КР
Так это не одно и то же. Абстрагировать это не получится.
При замене ничего не сломается, но станет по-лучше
VP
да, насратб, я вот и запилил себе инлайн-класс
Arr, у которого внутри стёртый массивУ себя можно что угодно делать, это не stdlib)
VP
При замене ничего не сломается, но станет по-лучше
Не сломается, серьёзно? А ничего, что DoubleArray не является Array?
AN
Это вообще довольно неприятный головняк. Я где-то уже писал об этом. Сейчас надо кучу кода дублировать, если ты хочешь работать и с массивами и с листами.
AN
Не сломается, серьёзно? А ничего, что DoubleArray не является Array?
Я не совсем про это говорил, а про автоспециализацю.
VP
Это вообще довольно неприятный головняк. Я где-то уже писал об этом. Сейчас надо кучу кода дублировать, если ты хочешь работать и с массивами и с листами.
Кстати в котлине нет такого интерфейса для списка, который был бы идентичен массиву. Ни List, ни MutableList не подходит.
AN
Кстати в котлине нет такого интерфейса для списка, который был бы идентичен массиву. Ни List, ни MutableList не подходит.
Потому что туда натянуто несколько лишних методов из Java Collections. Но добавить дефолтные реализации для недостающих методов и сделать MutableList не проблема.
VP
Потому что туда натянуто несколько лишних методов из Java Collections. Но добавить дефолтные реализации для недостающих методов и сделать MutableList не проблема.
А как их можно реализовать по-нормальному?
AN
А как их можно реализовать по-нормальному?
так же как в ArrayList
BP
Я вообще думаю, что Array<> - это стратегическая ошибка. Лучше бы его к листу сразу компилятором приводили
+
AN
Я исследовал вопрос. Кроме рефлексии вообще проблем нет.
VP
так же как в ArrayList
Ну это уже получится не просто обёртка над массивом, а ArrayList с исходным массивом в конструкторе.
AN
Ну это уже получится не просто обёртка над массивом, а ArrayList с исходным массивом в конструкторе.
Ну там выше писали. Представляем себе инлайновый ArrayList, убираем add/remove и вуаля
VP
Ну там выше писали. Представляем себе инлайновый ArrayList, убираем add/remove и вуаля
Так нельзя взять и убрать add/remove. Либо это MutableList, либо нет.