SB
Т.е. лучше это всё убрать что напридумывал и дёргать непосредственно nullable переменную, я правильно понял?
нет, поле сделать не нулабельным, и при присвоении явно делать ?: false
Size: a a a
2019 November 01
AL
Т.е. лучше это всё убрать что напридумывал и дёргать непосредственно nullable переменную, я правильно понял?
Ну скорее просто избавиться от null, а вместо него сделать default parameter:
class SomePojo(val bigList: Boolean = false)QH
кроме «да» и «нет» вполне может быть состояние «не знаю» :)
AO
Тут надо от кейса плясать, если не нужна логика при отсутсвии значения, то да ненулябельным надо делать
AL
Ну да. Т.е. если подавать на вход в pojo nullable, но использовать всегда non-nullable, то наверное стоит просто хранить non-nullable :)
Если нужно и то, и другое - я бы скорее тогда на месте использования делал ?: false или == true, но это вкусовщина, можно конечно и расширение накинуть.
Если нужно и то, и другое - я бы скорее тогда на месте использования делал ?: false или == true, но это вкусовщина, можно конечно и расширение накинуть.
AO
Ну да. Т.е. если подавать на вход в pojo nullable, но использовать всегда non-nullable, то наверное стоит просто хранить non-nullable :)
Если нужно и то, и другое - я бы скорее тогда на месте использования делал ?: false или == true, но это вкусовщина, можно конечно и расширение накинуть.
Если нужно и то, и другое - я бы скорее тогда на месте использования делал ?: false или == true, но это вкусовщина, можно конечно и расширение накинуть.
Расширение можно накидывать для читаемости, тут же вообще что то странное
Н
нет, поле сделать не нулабельным, и при присвоении явно делать ?: false
там gson эту pojo собирает)
QH
ууу блин, ещё мапперов не хватало
VP
там gson эту pojo собирает)
Лучше объяснить Gson, как это надо делать правильно, чем править код
Н
А вообще, что лучше читается? Что лучше использовать, функции или вот такие переменные?
Или
fun selectedValues(): List<Value> {
return values.filter { it.selected }
}Или
val selectedValues: List<Value>
get() = values.filter { it.selected }
VP
А вообще, что лучше читается? Что лучше использовать, функции или вот такие переменные?
Или
fun selectedValues(): List<Value> {
return values.filter { it.selected }
}Или
val selectedValues: List<Value>
get() = values.filter { it.selected }
Н
Хмм. Судя по этому, вариант с пропертей тут лучше?
QH
Хмм. Судя по этому, вариант с пропертей тут лучше?
твой selectedValues сейчас работает за n памяти и O(n) времени, поэтому пропертя считается неуместной
Н
Ага, понял, спасибо
AN
твой selectedValues сейчас работает за n памяти и O(n) времени, поэтому пропертя считается неуместной
Я бы не сказал так однозначно, пропертю можно сделать lazy и реюзать. Я бы сказал, что четкого критерия где делать порпертю, а кгде метод нет.
BP
твой selectedValues сейчас работает за n памяти и O(n) времени, поэтому пропертя считается неуместной
будто что-то плохое
VP
Почему несмотря на наличие в coroutineScope SupervisorJob исключение IOException долетает до родителя?
VP
Или внутренние скоупы уже без SupervisorJob запускают корутину?