Что то я не пойму тогда как такое в котлине решается) Есть вот Объект в нем есть поля: имя, дата, доп параметръ

Доп параметра может не быть а может быть) ЧТо тут спроектировано не правильно?)

вот с let надо глянуть почитать

Так ведь let - одна из основных фишек

главное не улететь в it-hell

Там полно фишек) Но все сразу в голову не улеглось)

Этот it хелл это ппц

когда model?.let { it.field?.let{ ...

Вот поэтому мне было проще через !! чем черезе эти it

чем подменить ?? . просто освоением котлина не так давно занялся

все что не может быть null и инициализируется не сразу можно сделать lateinit

хоть it можно и переименовать но все равно это ппц

поздняя инициализация я знаю но бывают ситуации когда именно может быть null пример я привел выше

Вот поэтому мне было проще через !! чем черезе эти it

не проще, лучше на java тогда писать. "!!" - костыль, для перехода с джава, мол хочу вызвать метод и если там null то кинь мне NullPointer

let)

а если как тут цепочка из 5-7-10 то это будет it it it it it it it it it it.................. так наверное красивее и читабельнее и лучше)

такого не должно случиться

ладно на одном уровне вложенности есть неопределенность null/не-null, но чтоб на 2/3/4 и далее - явно признак того, что что-то не так

а если как тут цепочка из 5-7-10 то это будет it it it it it it it it it it.................. так наверное красивее и читабельнее и лучше)

именуешь параметр

+ есть apply

The !! Operator The third option is for NPE-lovers. We can write b!!, and this will return a non-null value of b (e.g., a String in our example) or throw an NPE if b is null: val l = b!!.length Thus, if you want an NPE, you can have it, but you have to ask for it explicitly, and it does not appear out of the blue.

inline fun <T, R> T?.ifNotNull(block: (T) -> R): R? { return block(this ?: return null) }

в доках не запрещено

ну, как-бы это сказать

если ты пишешь !!

значит уверен, что там не null

в доках не запрещено

Но тогда в чем смысл Kotlin использовать. Ты пишешь как на Java, это как купить iPad, что бы использовтаь его вместо доски для нарезки зелени

если уверен, что там не null - пойди и гарантируй это в параметрах метода.

Ок будем пробовать перестраиваться)

Спасибо за наводки)

ну и лично я стараюсь избегать складирования всего подряд в состояния

типа a = 10; doSomethingATimes();

тогда ситуации, в которых не ясно null/не-null возникают куда реже

Поверь, тут просто кажется что нельзя без "!!", потому что ты не перестроился, нужно в принципе иначе писать. Пишу проект сейчас на kotlin и не ни единого "!!"

если коротко - чистые функции рулят :)

+, !! сделано специально, чтобы ПРЯМ КРИЧАТЬ на опасные места в коде

!ОПАСНОСТЬ!

вот как они расшифровываются

вот счяс переписал строку где было !! с этим

но в конце теперь говорит что должен быть Int а приходит Int?

вооот

идешь уровнем выше

и смотришь как так получилось, что приходит то-ли Int, то-ли null

и постепенно искореняешь следы стохастического программирования

но в конце теперь говорит что должен быть Int а приходит Int?

Суть не в переписыании конкретной строки, нужно приучится писать все Immutable и не понадобятся ни "let" ни "!!")

радикал!

Ну как можно написать объект хранения состояний модели не изменяемым?

это новый уровень :) Список объектов состояний, каждый из которых копия исходного с измененными параметрами.

вот счяс переписал строку где было !! с этим

И да, ты же понимаешь, что написав там !! в случае Null ты получишь NullPointer? Но если ты сейчас можешь сказать: "Да нет, я же отписываюсь от Observsers в каком-нибудь onDestroy(), там точно не будет null", - тогда это только подтверждает, что можно писать так, что бы вообще не использовать !!

На каждый чих пересоздавать целиком объект?)

я и говорю - слишком радикально

На каждый чих пересоздавать целиком объект?)

А модель может быть null?

Не модель нулл а некоторые параметры могут быть нулл

У тебя: "model!!"

ViewModel может быть не инитнута

Это как?

Ну вот у меня окно для которой нечего хранить

И тогда у тебя нет модели? Неожиданно

https://github.com/Azoft/CarouselLayoutManager Господа, кто нибудь работал с этой замечательной каруселью? Она отлично работает, кроме проблемы с плавностью анимации, в моем сценарии. Дефолтный RecyclerView при этом не лагает

И тогда у тебя нет модели? Неожиданно

В смысле, если у тебя есть свойство model - почему оно вообще может быть когда-нибудь null? Если инициализируется сразу пишешь val, не сразу (к примеру через даггер) тогда lateinit var

Про отложенную инициализацию я знаю

Про отложенную инициализацию я знаю

Я просто пытаюсь донести, что использование null опасно, нужно избавлятся от него

Тем более что Kotlin позволяет это сделать

Я уже и не помню когда у меня приложение падало c NullPointer

А если наследуешься от ява класса то как избавится от этого?)

зависит от ситуации

А если наследуешься от ява класса то как избавится от этого?)

Писать Java класс так же нужно с умом. Я часто использую Immutable - объекты. Согласен, зависит от ситуации)

Immutable это не изменяемость объекта. Это не говорит о том что внутри 100% будут все поля

Immutable это не изменяемость объекта. Это не говорит о том что внутри 100% будут все поля

Нет, я же не о том, так легче дружить Java + Kotlin. Так же для самоконтроля можно использовать @NotNull or @NonNull

В третий раз стираю сообщение. ОЧЕНЬ непросто объяснить почему !! быть не должно и как этого достичь.

Вот больше интересует как этого достичь)

Как можно быть уверенным на 100% что все поля придут например)

Для этого ты должен обработать пришедшие модельки

Как можно быть уверенным на 100% что все поля придут например)

Только если то откуда они придут так же написаны нормально.

собственно, входные данные - единственное место, где может быть null, а из них по коду должно распространяться через ?.let

или типа того, трудновато описать

или типа того, трудновато описать

Согласен, нужно прочувствовать и пойдет дальше само

Только если то откуда они придут так же написаны нормально.

Ну снова возвращаюсь к примеру Объект: поля : имя, возраст, пармка(которая может придти а может не придти)

Ну снова возвращаюсь к примеру Объект: поля : имя, возраст, пармка(которая может придти а может не придти)

Ну как это может не прийти?

ну нет у кого то доп параметров

Значит то откуда приходит - работает странно

Есть поле а оно пустое

да нет, нормально работает

ок

ну доп параметр - это исключение ис правил, мы же говорим об общей картине

Чем странно? вот отрубят палец человеку и придет вместо 10 только 9 что странного?

живой пример - есть объект. Иногда у него могут быть данные о геолокации, иногда могут не быть

к примеру фото

Если ты работаешь с Api - оно документировано, и если не вернет что нужно - проблема Api и решать это нужно там

теперь у тебя есть 2 метода

первый отображает фото

ему плевать на данные о геолокации

второй отображает место, где оно сделано

photo.geo?.let{ showMap(it) }

живой пример - есть объект. Иногда у него могут быть данные о геолокации, иногда могут не быть

Ну дак это уже исключение, в основном в большинстве случаев не будет такой неопределенности

Если ты работаешь с Api - оно документировано, и если не вернет что нужно - проблема Api и решать это нужно там

почему не правильно??? ну нет в бд записи о твоих доп параметрах

В основном будет ещё не такая

Ну дак это уже исключение, в основном в большинстве случаев не будет такой неопределенности

так вот я тоже самое говорил

так вот

теперь внимание