@kotlin_lang

Страница 641 из 982
Dibro
18.04.2018
21:03:17
ай, там ещё генерики были(

Stas
18.04.2018
21:03:26
пробовал оба

Alexander
18.04.2018
21:09:25
https://youtrack.jetbrains.com/issue/KT-15952

Так что полагаю, что только Typealias

Google
Stas
18.04.2018
21:13:57
Aleksandr
18.04.2018
23:11:59
callable reference для конструктора sealed класса может работать?
у sealed классов приватный конструктор

Aleksandr
19.04.2018
06:00:00
в kotlin in action точно про это было

Mikhail
19.04.2018
06:00:13
Если ты про тот коонкретный класс, который sealed, то он абстрактный

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

Если бы конструктор был приватным, то класс был бы закрытым и нафиг он был бы нужен тогда sealed

Dmitriy
19.04.2018
06:20:32
для MVP пользуйся Moxy
почему не Mosby?

Sergey
19.04.2018
06:21:29
почему не Mosby?
Потом что mosby была вдохновителем

Petr
19.04.2018
06:21:59
для MVP пользуйся Moxy
а чем он лучше чем nucleus?

Dmitriy
19.04.2018
06:23:25
О! Они в MVI могут)

Sergey
19.04.2018
06:34:36
а чем он лучше чем nucleus?
Я высказал своё имхо, а холивар устраивать

Google
Petr
19.04.2018
06:35:25
Я высказал своё имхо, а холивар устраивать
я не про холивары на работе используем nucleus moxy не использовал, интересно что там есть интересного

Саша
19.04.2018
06:40:52
Привет всем, можете помочь с корутинами, дело не хитрое, еще просто не успел освоить, крч, я хочу сделать: - в одном бг потоке одно вычисление - параллельно во втором второе - когда они оба завершатся, то мне надо сделать Pair(a, b) подскажите что да как?

Жабра
19.04.2018
06:59:48
suspend fun compute(): Pair<A, B> { val deferred1 = async(CommonPool) { oneComputation() } val deferred2 = async(CommonPool) { otherComputation() } deferred1.await() to deferred2.await() }
А зачем явно указывать контекст? Если мне не изменяет память, DefaultDispatcher == CommonPool.

Лёша
19.04.2018
07:01:06
до какой-то версии надо было указывать явно видимо, по привычке)

whalemare
19.04.2018
07:23:06
Или чтобы понятнее было что там и откуда

Sergey
19.04.2018
07:49:43
я не про холивары на работе используем nucleus moxy не использовал, интересно что там есть интересного
ну жеж прочитайте введение =) я полистал wiki nucleus скупо, не ясно как мне запилить презентер для всех viewHolder

Щерба
19.04.2018
08:04:13
Всем привет! Как прогнать через цикл размерность массива? В Java так напиример for(int i = 0; response.body().data.size; i++) и в конечном итоге получает 1,2,4..... в котлин так не работает for (i in response.body().data.size)

Щерба
19.04.2018
08:07:02
Andrew
19.04.2018
08:07:33
или arr.forEachIndexed { i, value -> .. }

Щерба
19.04.2018
08:08:14
Круто всем спасибо!!!))

Vladislav
19.04.2018
10:37:23
В котлине нет частичной спецификации типов генерика, чтобы он взял один тип из параметра, а остальные можно было бы явно указать?

Vladislav
19.04.2018
10:38:42
Dibro
19.04.2018
10:40:59
типа можно же сделать fun <T> myMap() = mapOf<String, T>() или я совсем не о том?

Google
Quantum Harmonizer
19.04.2018
10:43:57
а как это вообще? не понимаю
ну тип mapOf<_, String> = ... — и на месте _ выведется

Dibro
19.04.2018
10:45:00
Quantum Harmonizer
19.04.2018
10:45:16
Эх
вот сюда вопрос)

Roman
19.04.2018
10:45:17
Для этого в Котлине есть функции. Заводишь свою функцию с одним типовым параметром и пользуешься.

Igor
19.04.2018
10:52:39
А есть где нибудь расжеванное объяснение, почему в rxjava zipWith в котлин не выводятся типы?

Stepan
19.04.2018
13:20:21
Интересно почему в Channels.kt есть public fun <E, R> ReceiveChannel<E>.map(context: CoroutineContext = Unconfined, transform: suspend (E) -> R): ReceiveChannel<R> = produce(context) { consumeEach { send(transform(it)) } } но нет чего-то вроде public fun <E, R> SendChannel<E>.contramap(context: CoroutineContext = Unconfined, transform: suspend (R) -> E): SendChannel<R> = actor(context) { consumeEach { send(transform(it)) } } ?

Vyacheslav
19.04.2018
14:08:21


помогите понять почему

Petr
19.04.2018
14:09:00
nullsafety потому что

Vladislav
19.04.2018
14:09:08
Для этого в Котлине есть функции. Заводишь свою функцию с одним типовым параметром и пользуешься.
Вот у меня есть примерно такой код, не соображу как с помощью функции выкрутиться? Не хочется указывать тип, который и так понятно что String class MyClass<K, V>(val key: K) { var value: V? = null } fun t() { val c = MyClass<_, Int>("key") }

Petr
19.04.2018
14:09:30
в котлине лучше хаписать arguments?.let{//logic//} код внутри выполнится если аргументы не нулл

Vyacheslav
19.04.2018
14:09:33
nullsafety потому что
я же сделал проверку внутри на налл

Petr
19.04.2018
14:09:45
Vyacheslav
19.04.2018
14:09:56
ну это я вкурсе но почему оно не хендлит проверку в доке вроде писалось что хендлит

просит элвиса

Alexey
19.04.2018
14:10:21
это не var случаем?

Vladislav
19.04.2018
14:10:45
arguments - это поле объекта this и от строки к строке оно может меняться, к примеру, в другом потоке. Поэтому каждый раз его надо чекать при доступе. О чем компилятор и говорит

Va
19.04.2018
14:10:48
это не var случаем?
var, подчеркнуто же

Roman
19.04.2018
14:10:57
Для переменных-пропертей смарт касты не работают.

Google
Roman
19.04.2018
14:11:32
допиши перед ифой val arguments = arguments

Alexey
19.04.2018
14:11:46
var, подчеркнуто же
делаю диагностику по подстветке в idea, недорого

Va
19.04.2018
14:12:19
делаю диагностику по подстветке в idea, недорого
дорого, просто первый раз бесплатный

Vyacheslav
19.04.2018
14:13:30
допиши перед ифой val arguments = arguments
отработало как боженька

Alexander
19.04.2018
14:14:37
отработало как боженька
Лучше последовать совету Петра с ?.let

Vyacheslav
19.04.2018
14:14:55
так делается только в случае если нужно вернуть результат

Petr
19.04.2018
14:15:00
Лучше последовать совету Петра с ?.let
а почему этот вариант лучше?

Vyacheslav
19.04.2018
14:15:02
мне не нужен результат

Roman
19.04.2018
14:16:20
Обилие let, apply, run и т.п. по моему опыту не делает код понятнее...

Они должны быть в местах, где без них не обойтись. Если можно обойтись ифой, лучше оставить ифу.

Alexander
19.04.2018
14:17:40
Нет лишних переменных, короче. И мне казалось, что его отмечали как идиоматичный. arguments?.let { it.getString(...) it.getString(...) }

Roman
19.04.2018
14:18:48
Плюсов у этих функций море, но есть один жирный минус - читаемость.

Albert
19.04.2018
14:19:19
Вкусовшина. Конструкция val arguments = arguments тоже выглядит странно на мой взгляд

Roman
19.04.2018
14:19:40
Хотя мб дело привычки, мб после лет 10 программирования на котлине и привыкну)

Petr
19.04.2018
14:19:45
Albert
19.04.2018
14:19:50
Плюсов у этих функций море, но есть один жирный минус - читаемость.
Мне кажется это для тех, кто не знаком с котлин

Alexander
19.04.2018
14:21:54
Ну, тут рекомендуется так: https://kotlinlang.org/docs/reference/idioms.html#execute-if-not-null А дальше уже решать самим, кому как удобнее.

Виталий
19.04.2018
14:24:34
Мне тоже shadowing кажется читабельней, без лишних вложенностей

кроме того если у тебя кроме if ничего в методе больше нет и не нужно возвращать значение из него, можно и так val arguments = arguments ?: return

Google
Alexander
19.04.2018
14:28:29
Мне тоже shadowing кажется читабельней, без лишних вложенностей
Вот тут наверное не понял. Вложенность одна и та же, в одном случае её даёт let, в другом - if

Виталий
19.04.2018
14:28:58
Мне тоже shadowing кажется читабельней, без лишних вложенностей
а с let, у тебя либо есть ни о чём не говорящий it, либо ты задаёшь имя параметру и это уже не особо отличается от shadowing

Alexander
19.04.2018
14:34:15
ну в таком кейсе, например, нет вложенности вообще)
arguments?.let(::someExecuteMethod) Тут тоже. Но мы же рассматривали именно тот кейс :)

Виталий
19.04.2018
14:36:00
ну с одним полем ещё как-то норм, а если у тебя 3 поля и тебе нужно какие-то сравнения сделать, let уже совсем грустны)

Alexander
19.04.2018
14:36:01
а с let, у тебя либо есть ни о чём не говорящий it, либо ты задаёшь имя параметру и это уже не особо отличается от shadowing
Я искренне верю в способность программиста держать контекст пары строчек в голове. Ну или просто посмотреть подсказку идеи. Если строк много - да, наверное лучше гарды или вынесение в отдельный метод.

Bogdan
19.04.2018
15:02:51
Еще идиоматичней: arguments?.apply { getString(...) getString(...) }
apply - возращает this, run будет боле подходящим

Kirill
19.04.2018
15:48:37
у нас же, наверное, тут есть студенты: https://jetbrains.ru/students/internship/themes/scala-to-kotlin-converter/

Sergey
19.04.2018
16:01:03
тонко

Страница 641 из 982