IN
да я понял .
Size: a a a
2020 February 13
SB
Так как это разные юниты компиляции, никто не мешает в следующей версии этому полю стать var
а есть какой-нибудь флаг компилятора, чтоб ему сказать "да я верю этому модулю, братан, падай в рантайме если что", вместо оператора "мамой клянусь"
!! ?SB
а то правда напрягает периодически что это val, я сам автор второго модуля, подгружаю его конкретную версию, но смарткаста после проверки поля на null не происходит. Насчет того что он станет var в другой версии модуля там будет уже проверка именно на var , а не на модульность же
AO
Я просто всегда делаю через ?.let
BP
Потому что нет гарантий, что значение не изменится на null после проверки
Да вроде не вар
SB
Я просто всегда делаю через ?.let
итого человеческий
if (smth != null) else превратится в ?.let {} ?: , вроде и не особо плохо, но конструкция менее очевиднаяAL
Да вроде не вар
Computable property тоже никто не отменял :)
AO
итого человеческий
if (smth != null) else превратится в ?.let {} ?: , вроде и не особо плохо, но конструкция менее очевиднаявай соу?
VP
а есть какой-нибудь флаг компилятора, чтоб ему сказать "да я верю этому модулю, братан, падай в рантайме если что", вместо оператора "мамой клянусь"
!! ?Это больше на контракт похоже
"Да не буду я возвращать null, если сейчас не null"
"Да не буду я возвращать null, если сейчас не null"
VP
Может, запилят когда-нибудь
SB
вай соу?
ну потому что условия могут быть не просто проверка на нулл, а какая-нибудь комбинируемая логика, или несколько нон-нулл проверок
BP
Функция + контракт, Правда они пока ограниченные
AO
ну потому что условия могут быть не просто проверка на нулл, а какая-нибудь комбинируемая логика, или несколько нон-нулл проверок
Ну вот без нескольких проверок можно как то так
foo.bar
?.takeIf { for.baz == "kek" }
?.let { bar -> doSomeShit(bar) }
?: doOtherShit()
AO
С двумя != null конечно сложнее, но тоже можно вывернуться
SB
С двумя != null конечно сложнее, но тоже можно вывернуться
ну вот в том и дело, что вывернуться) я не против подобного стиля, но где можно написать вполне себе явный if-else, почему бы этого не сделать
а с этой проверкой приходится ставить везде !! дальше
а с этой проверкой приходится ставить везде !! дальше
IN
а то правда напрягает периодически что это val, я сам автор второго модуля, подгружаю его конкретную версию, но смарткаста после проверки поля на null не происходит. Насчет того что он станет var в другой версии модуля там будет уже проверка именно на var , а не на модульность же
Так это штука не от чего не защищает.) Если у тебя зависимость от второго модуля и 1 модуль обновили , а твой нет и там были изменения этого поля, то все равно сломается все.
IN
если модули jar
АО
а то правда напрягает периодически что это val, я сам автор второго модуля, подгружаю его конкретную версию, но смарткаста после проверки поля на null не происходит. Насчет того что он станет var в другой версии модуля там будет уже проверка именно на var , а не на модульность же
val - property, а не переменная, а значит между вызовами соседних строк может произойти что угодно
АО
В общем-то, всё логично
SB
val - property, а не переменная, а значит между вызовами соседних строк может произойти что угодно
не понял посыла