Size: a a a

Kotlin Community

2020 February 13

BV

Boris Vanin in Kotlin Community
Ну там с какой стороны писать какую часть ассершена
источник

AO

Alexey Otts in Kotlin Community
Boris Vanin
Ну там с какой стороны писать какую часть ассершена
Ну я should матчерами пользуюсь там вроде всё понятно
источник

BV

Boris Vanin in Kotlin Community
Есть should, есть shouldBe, есть shoulsNoBe и ещё куча продолжений
источник

M

Mike in Kotlin Community
Подскажите, в чем принципиальное различие в подключении плагина из buildSrc, написанного на groovy,   и плагина, написанного на kotlin?
источник

LS

Lev Shagalov in Kotlin Community
Boris Vanin
Есть should, есть shouldBe, есть shoulsNoBe и ещё куча продолжений
Это что за should? Откуда?

Вообще инфиксы отлично смотрятся когда нет цепочки вызовов. Когда цепочка вызовов есть - инфиксы яно не к месту
источник

BP

Bogdan Panchenko in Kotlin Community
Mike
Подскажите, в чем принципиальное различие в подключении плагина из buildSrc, написанного на groovy,   и плагина, написанного на kotlin?
статическая типицаия
источник

BV

Boris Vanin in Kotlin Community
Mike
Подскажите, в чем принципиальное различие в подключении плагина из buildSrc, написанного на groovy,   и плагина, написанного на kotlin?
Ну, во-первых, он написан на котлине. Это основное принципиальное отличие
источник

AO

Alexey Otts in Kotlin Community
Boris Vanin
Есть should, есть shouldBe, есть shoulsNoBe и ещё куча продолжений
Ну да, оно всё слизано со spec, так что мне привычно
источник

AO

Alexey Otts in Kotlin Community
Lev Shagalov
Это что за should? Откуда?

Вообще инфиксы отлично смотрятся когда нет цепочки вызовов. Когда цепочка вызовов есть - инфиксы яно не к месту
Kotlintest
источник

K

Kopusha in Kotlin Community
FYI, месяц назад меня тут отговаривали делать такое:

@Suppress("NO_REFLECTION_IN_CLASS_PATH")
private val itemTypes = ListItem::class.sealedSubclasses

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

TL;DR объявляйте зависимости явно :)
источник

B

Beholder in Kotlin Community
Как объяснить ошибку "Private setters are not allowed for open properties"? Смутно догадываюсь, но что-то не до конца.
источник

AM

Andrew Mikhaylov in Kotlin Community
Beholder
Как объяснить ошибку "Private setters are not allowed for open properties"? Смутно догадываюсь, но что-то не до конца.
А как вы себе представляете переопределение этой проперти в наследнике? Приватный сеттер, который невозможно переопределить, ведь он даже не виртуальный метод, будет влиять на одно значение, а геттер будет в наследнике что-то другое делать?
источник

B

Beholder in Kotlin Community
Чем грозит, например, вот это? https://pastebin.com/mzZvFDjP
источник

B

Beholder in Kotlin Community
Приходится либо переопределять свойство как final, либо вводить backing field
источник

RI

Ruslan Ibragimov in Kotlin Community
источник

B

Beholder in Kotlin Community
Переопределить только геттер,  а сеттер пусть работает как раньше
источник

RI

Ruslan Ibragimov in Kotlin Community
Проперти не final, что произойдет если наследник переопределит setter?
источник

AM

Andrew Mikhaylov in Kotlin Community
Beholder
Переопределить только геттер,  а сеттер пусть работает как раньше
Это очень странное желание, как по мне. Хотите сделать такое -- сделайте полностью приватный backing property и open val, геттер которого возвращает эту пропертю.
источник

AM

Andrew Mikhaylov in Kotlin Community
Ruslan Ibragimov
Проперти не final, что произойдет если наследник переопределит setter?
Наследник не переопределит приватный сеттер же.
источник
2020 February 14

VP

Vladimir Petrakovich in Kotlin Community
Beholder
Приходится либо переопределять свойство как final, либо вводить backing field
А чем плох первый вариант?
источник