BV
Ну там с какой стороны писать какую часть ассершена
Size: a a a
2020 February 13
AO
Ну там с какой стороны писать какую часть ассершена
Ну я should матчерами пользуюсь там вроде всё понятно
BV
Есть should, есть shouldBe, есть shoulsNoBe и ещё куча продолжений
M
Подскажите, в чем принципиальное различие в подключении плагина из buildSrc, написанного на groovy, и плагина, написанного на kotlin?
LS
Есть should, есть shouldBe, есть shoulsNoBe и ещё куча продолжений
Это что за should? Откуда?
Вообще инфиксы отлично смотрятся когда нет цепочки вызовов. Когда цепочка вызовов есть - инфиксы яно не к месту
Вообще инфиксы отлично смотрятся когда нет цепочки вызовов. Когда цепочка вызовов есть - инфиксы яно не к месту
BP
Подскажите, в чем принципиальное различие в подключении плагина из buildSrc, написанного на groovy, и плагина, написанного на kotlin?
статическая типицаия
BV
Подскажите, в чем принципиальное различие в подключении плагина из buildSrc, написанного на groovy, и плагина, написанного на kotlin?
Ну, во-первых, он написан на котлине. Это основное принципиальное отличие
AO
Есть should, есть shouldBe, есть shoulsNoBe и ещё куча продолжений
Ну да, оно всё слизано со spec, так что мне привычно
AO
Это что за should? Откуда?
Вообще инфиксы отлично смотрятся когда нет цепочки вызовов. Когда цепочка вызовов есть - инфиксы яно не к месту
Вообще инфиксы отлично смотрятся когда нет цепочки вызовов. Когда цепочка вызовов есть - инфиксы яно не к месту
Kotlintest
K
FYI, месяц назад меня тут отговаривали делать такое:
Правильно отговаривали! Прогард порезал неявную зависимость на рефлекшн и в релизной сборке в рантайме этот массив будет пустым.
TL;DR объявляйте зависимости явно :)
@Suppress("NO_REFLECTION_IN_CLASS_PATH")
private val itemTypes = ListItem::class.sealedSubclasses
Правильно отговаривали! Прогард порезал неявную зависимость на рефлекшн и в релизной сборке в рантайме этот массив будет пустым.
TL;DR объявляйте зависимости явно :)
B
Как объяснить ошибку "Private setters are not allowed for open properties"? Смутно догадываюсь, но что-то не до конца.
AM
Как объяснить ошибку "Private setters are not allowed for open properties"? Смутно догадываюсь, но что-то не до конца.
А как вы себе представляете переопределение этой проперти в наследнике? Приватный сеттер, который невозможно переопределить, ведь он даже не виртуальный метод, будет влиять на одно значение, а геттер будет в наследнике что-то другое делать?
B
Приходится либо переопределять свойство как final, либо вводить backing field
RI
Чем грозит, например, вот это? https://pastebin.com/mzZvFDjP
B
Переопределить только геттер, а сеттер пусть работает как раньше
RI
Проперти не final, что произойдет если наследник переопределит setter?
AM
Переопределить только геттер, а сеттер пусть работает как раньше
Это очень странное желание, как по мне. Хотите сделать такое -- сделайте полностью приватный backing property и open val, геттер которого возвращает эту пропертю.
AM
Проперти не final, что произойдет если наследник переопределит setter?
Наследник не переопределит приватный сеттер же.
2020 February 14
VP
Приходится либо переопределять свойство как final, либо вводить backing field
А чем плох первый вариант?