выкинь нафиг котлин и пиши начем хочешь, не *би мозг, тебя не заставляем

Не обделайся только смотри)

Ты пиши с вложенным массивом и посмотри что красивше Array<Array<Element» или [][] ;)

И так же с инициализацией, да.

Если элемент кастомный особенно.

омагад, скобки не красивые

омагад, скобки не красивые

Красивее чем котлиновский вариант так точно)

Ты пиши с вложенным массивом и посмотри что красивше Array<Array<Element» или [][] ;)

в этом случае нуллабле юзать нада, но масивы не тот выбор. Мутадельные колекции

в этом случае нуллабле юзать нада, но масивы не тот выбор. Мутадельные колекции

Речь не о выборе решения. Вроде кричишь, что так же там на шарпе выглядит. Ан нет.

Я сейчас конечно для тебя америку открою, но массив - это по сути примитив, и в обычно жизни с ними никто не парится

Речь не о выборе решения. Вроде кричишь, что так же там на шарпе выглядит. Ан нет.

хватит оффтопить

Я сейчас конечно для тебя америку открою, но массив - это по сути примитив, и в обычно жизни с ними никто не парится

Не парься. А мне вот понадобилось, закрывай америку.

хватит оффтопить

Так ты это себе скажи. С решением вопроса ты не помог, а только покричал в чате и меня потянул за собой :)

Зачем, чем тебе ArrayList тот же не устроил?

Двумерные массивы это как бы вообще сахар

В тех же плюсах и сисарпах

Да и в джаве поди тоже

Зачем, чем тебе ArrayList тот же не устроил?

да забей на него

Есть только одномерные массивы

уважаемые эксперты давайте оставим мнения по language design при себе)

Вот я дурак, переписываю удобные даже на Java массивы с итерацией на стримы. https://github.com/bootique/bootique/commit/8adce30e36e4dc13c0ca041e3c57134b5b428377#diff-9dd089fea9c17106624d0c2a90654a7aL37

если производительность не критична в данном месте, то стримы будут читабельнее

тут тоже дело привычки

И эта инициализация по твоему лучше чем int[][] mm = int[][]?) Даже если котлиновский вариант упростить, убрать лямбду, она там в IntArray по умолчанию есть, убрать дженерики, всё равно получается дичь не красивая)

И эта инициализация по твоему лучше чем int[][] mm = int[][]?) Даже если котлиновский вариант упростить, убрать лямбду, она там в IntArray по умолчанию есть, убрать дженерики, всё равно получается дичь не красивая)

дело вкуса

И эта инициализация по твоему лучше чем int[][] mm = int[][]?) Даже если котлиновский вариант упростить, убрать лямбду, она там в IntArray по умолчанию есть, убрать дженерики, всё равно получается дичь не красивая)

пиши что хочешь

пиши что хочешь

Именно так и делаю. Но вопрос оказался нерешаемым. Котлин в это дело не могет, а жаль

если производительность не критична в данном месте, то стримы будут читабельнее

а что с производительностью стримов не так?

Оверхеды из-за сотни слоев абстракций

Но в принципе терпимо

если сравнить затраты на инициализацию + особенности, то перебор в цикле будет быстрее, но если не критично то норм. Смотрите бенчмарки, стримы немного медленнее циклов

Оверхеды из-за сотни слоев абстракций

Стримы — это ленивые обёртки над сплитераторами. Что делает их самым быстрым способом применить к коллекции несколько операторов и распараллелить вычисления.

Да я знаю, лол

а вот в котлине там inline, фактически в байткоде будет перебор в цикле.

если сравнить затраты на инициализацию + особенности, то перебор в цикле будет быстрее, но если не критично то норм. Смотрите бенчмарки, стримы немного медленнее циклов

«Смотрите бенчмарки» — это очень плохая аргументация, т. к. собственные бенчмарки показали мне обратное.

В студию результаты

а вот в котлине там inline, фактически в байткоде будет перебор в цикле.

Только если применять одну операцию. Для нескольких сиквенсы/стримы будут быстрее.

так и есть

на хабре много было бенчей

В студию результаты

Это было давно. Вкратце: на маленьких коллекциях циклы быстрее, на больших — стримы.

если есть что-то что показывает отличие кидайте ссылку

если есть что-то что показывает отличие кидайте ссылку

Так вы же говорите, что одно быстрее другого, от вас ссылки и ждут.

Ну если на размерах, то да при больших коллекциях разница несущественна

Ну если на размерах, то да при больших коллекциях разница несущественна

На больших коллекциях стримы существенно опережают всё остальное.

А сиквенсы?

А сиквенсы?

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

не оптимизировали еще

Совсем недавно в kotlin in action прочитал про сиквенсы подробнее. Не сказал бы, что не очень.

Совсем недавно в kotlin in action прочитал про сиквенсы подробнее. Не сказал бы, что не очень.

ну а я давно)

Когда много фильтровать и мапить надо... Эт очень полезная штука, как мне показалось

Когда много фильтровать и мапить надо... Эт очень полезная штука, как мне показалось

+

А сиквенсы?

Я проверял стримы до того, как узнал про Котлин, но при нескольких операциях сиквенсы обязательно обгонят простую работу с коллекциями. Они — как однопоточные стримы.

сиквенсы при больших коллекциях и множестве операций, а при малых коллекциях и небольшом количестве операций можно и без сиквенсов

сиквенсы при больших коллекциях и множестве операций, а при малых коллекциях и небольшом количестве операций можно и без сиквенсов

Ну это да

нехватает паралельности в сиквенсах

В смысле, зачем?

Народ, ау, говорить про производительность коллекций на 10 элементов - это вообще перебор

10 - это абстрактное число

подставьте своё

Да у нас просто элементы по гигабайту!

так для такого размера просто не надо сиквенсы юзать

Правильнее сказать, для такого размера насрать что юзать

ну, если не юзать сиквенсы, то тк компилится просто в цикл, то может быстрее

об этом сказано в kotlin in action

Там ведь еще фишка в промежуточных коллекциях

Точнее в том, что они не создаются

Там ведь еще фишка в промежуточных коллекциях

собственно, фишка исключительно в этом

Ну и еще в том, что оно не проверяет сразу все элементы, а каждый элемент по всей цепочке действий гоняет

Вроде бы правильно написал ?

народ подмогните плиз? а то я чего-то туплю. Как с помощью корутин сделать следующее: 1. нужно получить информацию из БД (не основной поток) 2. после получения информации необходимо обновить UI элемент (основной поток). при этом UI поток не должен блокироваться, все должно происходить в фоне

народ подмогните плиз? а то я чего-то туплю. Как с помощью корутин сделать следующее: 1. нужно получить информацию из БД (не основной поток) 2. после получения информации необходимо обновить UI элемент (основной поток). при этом UI поток не должен блокироваться, все должно происходить в фоне

именно то, что вам нужно: https://android.jlelse.eu/a-first-walk-into-kotlin-coroutines-on-android-fe4a6e25f46a

именно то, что вам нужно: https://android.jlelse.eu/a-first-walk-into-kotlin-coroutines-on-android-fe4a6e25f46a

спасибо. Буду изучать

Если ты пишешь под android-ktx нужен ли anko ?

хех, похоже на наброс ? (anko нужен если хочешь UI в коде)

В Anko планируют задепрекейтить то, что есть в KTX.

Ребят, а есть в Intellij команда, чтобы инсертнула все параметры конструктора? (пишешь такой Foo(... @ МАГИЧЕСКОЕ СОЧЕТАНИЕ КЛАВИШ @ Foo(bar = , baz = , ...) ) А то я в конец обленился

Ребят, а есть в Intellij команда, чтобы инсертнула все параметры конструктора? (пишешь такой Foo(... @ МАГИЧЕСКОЕ СОЧЕТАНИЕ КЛАВИШ @ Foo(bar = , baz = , ...) ) А то я в конец обленился

не очень понятно чего ты хочешь? вставить при вызове конструктора перед каждым параметром его имя в коде?

дя

ну вообще любой функции

но зачем? О_О

эмм

чтобы было легко прочтитать вызов конструктора дата класса на 6-7 параметров

Если параметры уже заполнены, то по альт энтер можно проименовать параметры

Ну и хот кей тоже можно назначить

неее

в том то и дело, что я только открыл скобочку

и делаю приблизительно такое: cmd+P -> посмотреть имя параметра -> начать писать его -> hit Tab -> repeat