котлин 1.1?

да

Зато он безопаснее, ты по идеи в Java должен вынесли в лок. переменную (а то вдруг ? др поток поменяет поле между проверкой и вызовом метода). Хотя теор., наверное можно было бы ослабить это требование для НЕ volatile свойств.

А если custom getter?

А если custom getter?

Тогда другое дело ?

можно

что можно сделать? =)

У нас и для val кустом геттер может вернуть null

Тогда другое дело ?

как это будет выглядеть?

что можно сделать? =)

return locationInteractor.onAppStop().takeIf{userStateInteractor.isUserLoggedIn && locationInteractor != null} ?: Completable.complete()

:)

как это будет выглядеть?

Тогда и запрещать

не уверен что именно так скомпилируется

но примерно

return locationInteractor.onAppStop().takeIf{userStateInteractor.isUserLoggedIn && locationInteractor != null} ?: Completable.complete()

Куда понятнее стало ? (perl стайл (зато в одну строчку))

Куда понятнее стало ? (perl стайл (зато в одну строчку))

да, согласен, что спорно

но примерно

спасибо за идею, хотя не могу сказать что прямо стало хорошо =) короче - да

да, согласен, что спорно

Кстати null можно заменить Default заглушками

return locationInteractor?.onAppStop().takeIf{userStateInteractor.isUserLoggedIn} ?: Completable.complete()

даже так

зачем вся эта возня с нулабилити и все эти запреты понятно. не понятно как с этим всем делать красивый код

с котлином сложно) Надо больее многословными языками пользоваться для красивого кода

зачем вся эта возня с нулабилити и все эти запреты понятно. не понятно как с этим всем делать красивый код

uncle Bob тоже по этому сокрушается https://habrahabr.ru/post/324122/

даже так

ага, понял

Кстати null можно заменить Default заглушками

в каком месте? в вызове?

в каком месте? в вызове?

Ну типа: private var locationInteractor: LocationInteractor = LocationInteractor.EMPTY (тип можно опустить)

Ну типа: private var locationInteractor: LocationInteractor = LocationInteractor.EMPTY (тип можно опустить)

а если у меня нет Empty?

а если у меня нет Empty?

DO IT ?

DO IT ?

надеюсь это шутка? или вы так реально делаете чтобы нулабилити побороть?

=)

а если у меня нет Empty?

А вообще это вопрос, почему у тебя зависимость на какой-то сервис разрешается не в конструкторе и может меняться.

uncle Bob тоже по этому сокрушается https://habrahabr.ru/post/324122/

Сколько кода мне придется изменить, когда я наконец узнаю, что кто-то действительно должен вернуть null в древе вызовов? Все эти ограничения, налагаемые этими языками, предполагают, что программист обладает совершенным знанием системы, до того как начать писать её. Тут не понял его аргумент, т.е. если у меня в языке нету такой проверки на уровне компиляции, (Java) и я вдруг решил где-то кинуть null, то переделывать код не нужно, все само разрулится что ли? ? В статье он говорит про тесты, они покажут что код упал - ок. Но от этого разве как-нибудь измениться объем работ по адаптации кода? Т.е. и так и так тебе нужно или совершенное знание системы до разработки или же адаптация к изменениям.

надеюсь это шутка? или вы так реально делаете чтобы нулабилити побороть?

В некоторых случаях это лучше, чем null. Например, emptyList().

А вообще это вопрос, почему у тебя зависимость на какой-то сервис разрешается не в конструкторе и может меняться.

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

Сколько кода мне придется изменить, когда я наконец узнаю, что кто-то действительно должен вернуть null в древе вызовов? Все эти ограничения, налагаемые этими языками, предполагают, что программист обладает совершенным знанием системы, до того как начать писать её. Тут не понял его аргумент, т.е. если у меня в языке нету такой проверки на уровне компиляции, (Java) и я вдруг решил где-то кинуть null, то переделывать код не нужно, все само разрулится что ли? ? В статье он говорит про тесты, они покажут что код упал - ок. Но от этого разве как-нибудь измениться объем работ по адаптации кода? Т.е. и так и так тебе нужно или совершенное знание системы до разработки или же адаптация к изменениям.

Меня др заинтересовало - не уж то в Swift есть checked excpetion? Я всегда думал что это было ошибка java (по этому их не было в др JVM языках).

Меня др заинтересовало - не уж то в Swift есть checked excpetion? Я всегда думал что это было ошибка java (по этому их не было в др JVM языках).

да, они в последних версиях добавили этот ад

мб оно там не так уж плохо реализовано как боб пишет, не знаю

его аргументы очень уж однобоки (это по котлину видно)

да, они в последних версиях добавили этот ад

Наверное там все скоро перейдут на Either (аля скала/и др функ языки)

Сколько кода мне придется изменить, когда я наконец узнаю, что кто-то действительно должен вернуть null в древе вызовов? Все эти ограничения, налагаемые этими языками, предполагают, что программист обладает совершенным знанием системы, до того как начать писать её. Тут не понял его аргумент, т.е. если у меня в языке нету такой проверки на уровне компиляции, (Java) и я вдруг решил где-то кинуть null, то переделывать код не нужно, все само разрулится что ли? ? В статье он говорит про тесты, они покажут что код упал - ок. Но от этого разве как-нибудь измениться объем работ по адаптации кода? Т.е. и так и так тебе нужно или совершенное знание системы до разработки или же адаптация к изменениям.

+1

Наверное там все скоро перейдут на Either (аля скала/и др функ языки)

Выглядит говновато, как обработка ошибок в Си: я вам верну результат или errno/errstr. Я использовал either в ситауции, когда в одном месте могут оказаться объекты двух разных типов. Например, ВКонтакте есть сообщения сообществ, следовательно, автор сообщения — пользователь или группа: Either<User, Group>.

Выглядит говновато, как обработка ошибок в Си: я вам верну результат или errno/errstr. Я использовал either в ситауции, когда в одном месте могут оказаться объекты двух разных типов. Например, ВКонтакте есть сообщения сообществ, следовательно, автор сообщения — пользователь или группа: Either<User, Group>.

Для этого же есть sealed

А вообще это вопрос, почему у тебя зависимость на какой-то сервис разрешается не в конструкторе и может меняться.

посмотрел почему так было сделано. есть кейс когда объект locationInteractor не успел инициализироваться (не было ситуации когда это нужно) а уже нужно завершить работу класса. при завершении нужно вызвать метод у locationInteractor, но только в том случае, если он был прежде инициализирован.

Для этого же есть sealed

У меня User и Group — интерфейсы.

посмотрел почему так было сделано. есть кейс когда объект locationInteractor не успел инициализироваться (не было ситуации когда это нужно) а уже нужно завершить работу класса. при завершении нужно вызвать метод у locationInteractor, но только в том случае, если он был прежде инициализирован.

?.

?.

блин, точно же. до сих пор не могу перестроиться и не вижу таких простых вариантов =))

У меня User и Group — интерфейсы.

Ну OK (хотя в том же Haskell он в основном для ошибок используется монада Either по разному работает в Left и Right)

Выглядит говновато, как обработка ошибок в Си: я вам верну результат или errno/errstr. Я использовал either в ситауции, когда в одном месте могут оказаться объекты двух разных типов. Например, ВКонтакте есть сообщения сообществ, следовательно, автор сообщения — пользователь или группа: Either<User, Group>.

а какой способ возврата ошибок ты считаешь более красивым?

Для этого же есть sealed

Ну и такой подход sealed class MessageAuthor { class User : MessageAuthor() class Group : MessageAuthor() } свяжет группу и пользователя по признаку авторства сообщения, что мне кажется довольно ужасным (сильное связывание).

а какой способ возврата ошибок ты считаешь более красивым?

На самом деле, мне не хватает checked exceptions. Когда я лезу в интернет, нужно *обязательно* делать это в try-catch. В ситуации, когда знаешь, что checked exception вылететь не может, меня бы устроил компактный синтаксис для } catch (e: IOException) { throw AssertionError(e) } И, конечно, в Java переборщили с Checked exceptions: CloneNotSupportedException, UnsupportedEncodingException должны быть Runtime.

Я бы не хотел, делая несколько последовательных запросов в интернет, проверять возвращаемое значение каждого (either).

rx не решает эту проблему?

rx не решает эту проблему?

Каким образом?

мне кажется проблема проверяемых исключений в том, что когда пишешь код тебя заставляют обработать исключение, но ты еще не знаешь и не понимаешь что это за исключение и что с ним делать

и вот в этом случае возникает боль

Каким образом?

легче связать последовательные запросы

то есть проблема не с самим механизмом, а с тем как его использует фреймворк.

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

мне кажется проблема проверяемых исключений в том, что когда пишешь код тебя заставляют обработать исключение, но ты еще не знаешь и не понимаешь что это за исключение и что с ним делать

inline fun pokemon(code: () -> R throws Throwable): R { try { return code() } catch (t: Throwable) { throw AssertionError(t) } }

легче связать последовательные запросы

Легче связать последовательные запросы, написав их в одном блоке кода, синхронно. И все исключения свалятся в один блок catch.

inline fun pokemon(code: () -> R throws Throwable): R { try { return code() } catch (t: Throwable) { throw AssertionError(t) } }

и что делает этот код? он ведь никак не обрабатывает ошибку?

то есть проблема не с самим механизмом, а с тем как его использует фреймворк.

Ну да, checked exceptions — это одна из тех штук, к которой надо подходить с большой осторожностью при проектировании API.

какой здесь толк от checked exceptions?

и что делает этот код? он ведь никак не обрабатывает ошибку?

Если бы в Kotlin были checked exceptions, этот метод помогал бы превратить их в unchecked там, где это нужно.

на мой взгляд было бы удобно если бы язык позволял просто описать исключения которые МОЖЕТ кидать метод но не обязывал вызывающую сторону эти исключения обрабатывать

как кстати всякие jackson/gson работают с either и sealed?

а в котлине есть either?

нет, но он пишется в 10 строчек

на мой взгляд было бы удобно если бы язык позволял просто описать исключения которые МОЖЕТ кидать метод но не обязывал вызывающую сторону эти исключения обрабатывать

Kotlin позволяет: @Throws. Кто-нибудь на это смотрит при использовании API-ев?

можно Pair заюзать)

ERROR: S client not available

На самом деле, мне не хватает checked exceptions. Когда я лезу в интернет, нужно *обязательно* делать это в try-catch. В ситуации, когда знаешь, что checked exception вылететь не может, меня бы устроил компактный синтаксис для } catch (e: IOException) { throw AssertionError(e) } И, конечно, в Java переборщили с Checked exceptions: CloneNotSupportedException, UnsupportedEncodingException должны быть Runtime.

О да, это как IO монада тоже постоянно заставляет думать об I/O ошибках. С ней сама возможность ошибки (и сайд эффектов) прописывается в сигнатуру функции.

как кстати всякие jackson/gson работают с either и sealed?

Ну, должна быть договорённость между структурой и десериализатором. sealed как таковой не представляет проблем, пока не понадобидся полиморфный парсинг.

я вот кстати подумал, что для nullable не хватает тогого варианта когда изначально свойство может быть null, но перейти из не null в null уже не может. тогда проверки типа if (value != null) не будут требовать дополнительного кода

у меня в коде достаточно много именно таких кейсов

я вот кстати подумал, что для nullable не хватает тогого варианта когда изначально свойство может быть null, но перейти из не null в null уже не может. тогда проверки типа if (value != null) не будут требовать дополнительного кода

Delegates.notNull ?

я вот кстати подумал, что для nullable не хватает тогого варианта когда изначально свойство может быть null, но перейти из не null в null уже не может. тогда проверки типа if (value != null) не будут требовать дополнительного кода

lateinit

^^ эти двое в целом ведут себя идентично, только lateinit хранит реальный null, а notNull — делегат.

uncle Bob тоже по этому сокрушается https://habrahabr.ru/post/324122/

Эта статья похожа на батхёрт

^^ эти двое в целом ведут себя идентично, только lateinit хранит реальный null, а notNull — делегат.

оба эти варианта же не позволяют работать со свойством пока оно null? они требуют инициализации на момент использования. а я говорю про случай когда свойство nullable, но такой одноразовый nullable

оба эти варианта же не позволяют работать со свойством пока оно null? они требуют инициализации на момент использования. а я говорю про случай когда свойство nullable, но такой одноразовый nullable

Они расценивают свойство как не-нуллабельное, считая, что об инициализации ты позаботишься самостоятельно.

Они расценивают свойство как не-нуллабельное, считая, что об инициализации ты позаботишься самостоятельно.

в моем случае инициализация не всегда происходит. это один из нормальных кейсов

то есть это nullable которому null можно присвоить только при изначальной инициализации

Всем привет, осваиваю котлин на андроиде, сейчас пишу адаптер для recyclerView, кто то может объяснить пожалуйста простыми словами какая разница между строками и какую правильно выбрать ? 1)holder?.item?.text = items[position] 2)holder!!.item.text = items[position] Как я понимаю во втором варианте если holder null, то всё просто падает

то есть это nullable которому null можно присвоить только при изначальной инициализации

Ему никак нельзя присвоить null :)

да, правильно. в первом варианте код может молча не отработать

Ему никак нельзя присвоить null :)

я про свой несуществующий в языке вариант говорю, которого мне не хватает

зачем кстати нужен Delegates.NotNull если есть lateinit?

я про свой несуществующий в языке вариант говорю, которого мне не хватает

Можно написать свой делегат, который будет работать, как в Java.

Всем привет, осваиваю котлин на андроиде, сейчас пишу адаптер для recyclerView, кто то может объяснить пожалуйста простыми словами какая разница между строками и какую правильно выбрать ? 1)holder?.item?.text = items[position] 2)holder!!.item.text = items[position] Как я понимаю во втором варианте если holder null, то всё просто падает

Может, можно сделать holder не-нуллабельным?

Тут еще вопрос с чего это он recyclerView вообще null?

Можно написать свой делегат, который будет работать, как в Java.

а как это сделать? если тип свойства не будет nullable то как проверить на null? а если будет, то как делегат поможет решить проблему нерабочего смарткаста при проверке?

Может, можно сделать holder не-нуллабельным?

Да, так действительно проще)

а как это сделать? если тип свойства не будет nullable то как проверить на null? а если будет, то как делегат поможет решить проблему нерабочего смарткаста при проверке?

Можно хранить сам делегат в отдельном поле, например: private val _something = SomeDelegate() val something by _something но это, конечно, костыль.

Хм. Есть класс, у него должен быть no-arg constructor, которым будет пользоваться фреймворк. Есть пара статических фабрик, которые используют этот конструктор. Как бы мне так ограничить доступ к конструктору, чтобы из нормального кода использовались только фабрики?

Хм. Есть класс, у него должен быть no-arg constructor, которым будет пользоваться фреймворк. Есть пара статических фабрик, которые используют этот конструктор. Как бы мне так ограничить доступ к конструктору, чтобы из нормального кода использовались только фабрики?

а private конструктор твой фреймворк не скушает?

Android. Кажется, не скушает.

Android. Кажется, не скушает.

фрагменты ?

@Deprecated(level = DeprecationLevel.ERROR, message = "for reflective use by Android") constructor() : super() private constructor(args: Bundle) : super() { arguments = args }

Хм. Есть класс, у него должен быть no-arg constructor, которым будет пользоваться фреймворк. Есть пара статических фабрик, которые используют этот конструктор. Как бы мне так ограничить доступ к конструктору, чтобы из нормального кода использовались только фабрики?

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

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

Не. Android вызовет setArguments когда пересоздаст объект.

аа, вон ты какой хитрый, хочешь сразу внутри аргументы внутри конструктора установить.

=)