Код дико красивый, но в чём фишка возвращать Tree? Метод add, по идее, должен быть Unit.

Чтобы писать builder-подобные конструкции: add(one).add(two) и т.д.

Есть же apply

Чтобы писать builder-подобные конструкции: add(one).add(two) и т.д.

Я понимаю, но мне такой вариант не по нраву.

Я понимаю, но мне такой вариант не по нраву.

» в чём фишка возвращать Tree? » Я понимаю

"в чём фишка" подразумевалось под идиоматичностью построения самого дерева.

при вызове из меинтреда все отлично работает. если же в runBlocking передать контекст (UI) , то намертво блокирует меин тред. PS: дело происходит на андроиде

Название runBlocking как бы намекает.

Привет всем. Хотел поинтересоваться: как правильно понимать Thread-safety для kotlin (или, может, по этому поводу не нужно париться и в самом языке есть решение)? Нашел только то, что касается coroutine, но этот функционал еще эксперементальный. Еще натыкался вот на это: https://stackoverflow.com/questions/42479009/kotlin-local-variable-thread-safety https://discuss.kotlinlang.org/t/non-volatile-vs-volatile-captured-refs-by-default/2122/1 Правильно ли я понимаю из последнего, что в Kotlin не особо нужно беспокоиться по поводу volatile и в целом проблем связанных с concurrency? P.S. Буду рад любой инфе. Если что-то сформулировал не так — не бейте, я только только начал изучать :)

Привет всем. Хотел поинтересоваться: как правильно понимать Thread-safety для kotlin (или, может, по этому поводу не нужно париться и в самом языке есть решение)? Нашел только то, что касается coroutine, но этот функционал еще эксперементальный. Еще натыкался вот на это: https://stackoverflow.com/questions/42479009/kotlin-local-variable-thread-safety https://discuss.kotlinlang.org/t/non-volatile-vs-volatile-captured-refs-by-default/2122/1 Правильно ли я понимаю из последнего, что в Kotlin не особо нужно беспокоиться по поводу volatile и в целом проблем связанных с concurrency? P.S. Буду рад любой инфе. Если что-то сформулировал не так — не бейте, я только только начал изучать :)

Все так же, как в java

Привет всем. Хотел поинтересоваться: как правильно понимать Thread-safety для kotlin (или, может, по этому поводу не нужно париться и в самом языке есть решение)? Нашел только то, что касается coroutine, но этот функционал еще эксперементальный. Еще натыкался вот на это: https://stackoverflow.com/questions/42479009/kotlin-local-variable-thread-safety https://discuss.kotlinlang.org/t/non-volatile-vs-volatile-captured-refs-by-default/2122/1 Правильно ли я понимаю из последнего, что в Kotlin не особо нужно беспокоиться по поводу volatile и в целом проблем связанных с concurrency? P.S. Буду рад любой инфе. Если что-то сформулировал не так — не бейте, я только только начал изучать :)

+ к ответу выше. Всё так же. Только volatile и synchronized перешли в аннотации. Где-то в документации это вроде бы даже есть, но не помню точно

Да, аннотации я видел

Спасибо :)

Как известно BigDecimal("10") != BigDecimal("10.00") Ребят, как вы сравниваете BigDecimal? Неужели всегда пишете compareTo ? Я уже подумываю унаследоваться от BigDecimal и переопределить equals ...

Хай, народ, особенно андроидщики. Кто нить юзал для DI специальные котлиновские либы, типа KoDeIn, KoIn, Kapsule? Или все еще на даггере сидите? Просто дагер реально довольно усложненный и заточеный под джаву. А всякие котлиновские DI либы могут быть поидиоматичнее и полаконичние, да и поприятнее в общем. Но кулстори кто их успешно или неуспешно юзал я не слышал. Может тут есть, кто колупал?

Хай, народ, особенно андроидщики. Кто нить юзал для DI специальные котлиновские либы, типа KoDeIn, KoIn, Kapsule? Или все еще на даггере сидите? Просто дагер реально довольно усложненный и заточеный под джаву. А всякие котлиновские DI либы могут быть поидиоматичнее и полаконичние, да и поприятнее в общем. Но кулстори кто их успешно или неуспешно юзал я не слышал. Может тут есть, кто колупал?

Не юзал, но мне кажется даггер на котлине тоже достаточно прост

не сложнее, чем на джаве, но на и джаве бывает сложноватым)

Посмотрел кодеин, ну такое себе) еще один дсл учить чтобы зависимости тянуть)

И вот это смотрится достаточно страшно https://github.com/SalomonBrys/Kodein/blob/master/kodein-android/src/main/java/com/github/salomonbrys/kodein/android/AndroidModule.kt

после спринга реально смотремно

ну тут с даггером надо сравнивать

Ну, скажем так. В продакшене я бы это не юзал, потому что код должен быть поддерживаемым. Мало кто может в кодеин и вряд ли сможет в ближайшее время Но если пилить проект в одного или для себя то может быть

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

значит быстро входить можно

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

хм. Возможно, надо детальнее рассмотреть

да я тоже не юзал просто прочитал типа отзывы от компаний которые в проде юзают)

это просто первое впечатление от класса на 400 строк и минимум длинны строки в 100 символов)

кодеин забавно гуглить)

это просто первое впечатление от класса на 400 строк и минимум длинны строки в 100 символов)

ну просто надо сравнивать с тем, каким был бы даггеровский модуль, который провайдит все эти депенденси

имхо ад был бы более адовый

я думал даггер всем нравится)

особенно когда не собирается из-за ошибок в кодогенерации)

с аннтоациями достаточно лаконично и понятно что к чему) ну по крайней мере мне, потому что долго с ним уже вожусь.

ну он же не собирается потому что ты ошибся)

+

и хорошо что не собирается, а то если бы собирался...

а не просто так)

ну и npe в джава проектиках падали, потому что ты ошибся) но котлин с этим воюет же

ну failfast если бы код генерился а потом падал то было бы хуже)

но в любом случае лучше, когда проще. И вопрос, реально ли все эти кодеины решают?

Название runBlocking как бы намекает.

А то что блокирует навсегда меин, так и должно быть? Я подразумевал что только на время эвейта

Народ - а если я попрошу кого нибудь скинуть копию книги Kotlin for android developers (если конечно же она у кого то есть) мне справедливо ответят - "Ну купи же" или все таки скинут?

это антонио лейвы которая?

Народ - а если я попрошу кого нибудь скинуть копию книги Kotlin for android developers (если конечно же она у кого то есть) мне справедливо ответят - "Ну купи же" или все таки скинут?

Или загугли

это антонио лейвы которая?

верно.

Спасибо большое

А есть какие-нибудь опунсурс небольшие проекты на Kodein? Хотелось бы на код посмотреть

Привет ребят

как протестить var внутри интерфейса с мокито?

А есть какие-нибудь опунсурс небольшие проекты на Kodein? Хотелось бы на код посмотреть

Попробуй поискать на GitHub проекты с тегом kodein и Kotlin

interface Test{ var testVar } @Mock lateinit var test: Test @Test fun test{ val something = SomeClass(test) assertEquals(test.testVar, someValue) }

interface Test{ var testVar } @Mock lateinit var test: Test @Test fun test{ val something = SomeClass(test) assertEquals(test.testVar, someValue) }

для кода есть троные бэктики

Чет не понял а зачем это тестить

@antonkazakov это просто пример

Кому-нибудь "спасла жизнь" nonnull безопасность? Мне пока что она доставляет только головную боль. Хотя я новичок и возможно чего-то не понимаю, но в таком случае объясните, пожалуйста.

у тебя хоть раз нпе было?)

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

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

И тесты написать не забудешь? (анклабоба что ли почитал про “darkpath”?)

Не понял вас

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

лол

Жизнь разделилась на ДО и ПОСЛЕ

ERROR: S client not available

это все лирика, но Вы думаете в JetBrains просто из-за своей прихоти прикрутили сей функционал в Kotlin?

наверное парни что-то в этом понимают

Нет, ясное дело. Потому и прошу объяснить.

это все лирика, но Вы думаете в JetBrains просто из-за своей прихоти прикрутили сей функционал в Kotlin?

Потому что Роман предложил ? (надо его и спросить)

NULL вообще штука коварная, городить приходится в джаве постоянно на него проверки, а особо ушлые парни даже завязывают логику на NULL, это в корне не верный подход. И ладно если у вас приложение, типа CRM самопальная на заводе по производству унитазов, а если вы библиотеку пишите классную, которой весь мир пользуется? Вы им [пользователям своей либы] предлагаете проверки на NUL везде пихать?

это все лирика, но Вы думаете в JetBrains просто из-за своей прихоти прикрутили сей функционал в Kotlin?

Имхо в сложных проектах ты за всеми npe не уследишь.

унитазы тоже нужны

а опшионалы не решают эти пробелмы в джаве?

Имхо в сложных проектах ты за всеми npe не уследишь.

nullsafe не панацея конечно же, но все-таки совсем глупых вещей позволяет избежать на этапе разработки

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

JS -> Java -> Kotlin -> Rust(вроде)

в котлине я чаще стал nullable юзать

NULL вообще штука коварная, городить приходится в джаве постоянно на него проверки, а особо ушлые парни даже завязывают логику на NULL, это в корне не верный подход. И ладно если у вас приложение, типа CRM самопальная на заводе по производству унитазов, а если вы библиотеку пишите классную, которой весь мир пользуется? Вы им [пользователям своей либы] предлагаете проверки на NUL везде пихать?

Как-то живут же без nullsafe

Нет, ясное дело. Потому и прошу объяснить.

ты создаёшь новый яп с чистого листа. ты бы стал добавлять в тип целых чисел совершенно постороннее значение не имеющее ничего общего с целыми числами? и более того это значение присутствовало бы и во всех других типах

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

А молча прожевать нулл - тоже "так себе" идея

и все-таки nullsafe больше благо, нежели обратное. я считаю.

в эксепшне должна быть логика: ошибка io, коннекшена с бд и т.д. в NPE ее нет, она означает лишь упущение программиста. поэтому если использовать нуллы как часть логики приложения, то логично заставить программиста явно это указывать и следить за этим

nullsafe не панацея конечно же, но все-таки совсем глупых вещей позволяет избежать на этапе разработки

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

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

а вот для этого надо unit-тесты писать) и проверять граничные значения)

Как-то живут же без nullsafe

В Java и без data class живут, а в groovy без стат. типизации - ну почему бы тебе на них не писать. Чем больше компилятор проверит, тем меньше нам тестов писать и делать ручных проверок - это же всегда хорошо было (некоторые любители clojure с этим не согласны конечно)

а вот для этого надо unit-тесты писать) и проверять граничные значения)

так jsники говорят) что нам не нужна система типов и строгая типизация, мы тесты пишем. Но все же чем больше возьмет на себя система типизации, тем лучше

а вот для этого надо unit-тесты писать) и проверять граничные значения)

не силен в юнит тестировании, но есть еще такой момент как многопоточность)

так jsники говорят) что нам не нужна система типов и строгая типизация, мы тесты пишем. Но все же чем больше возьмет на себя система типизации, тем лучше

согласимся

Не понял вас

http://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath.html

Спасибо всем.

приходи еще)

В Java и без data class живут, а в groovy без стат. типизации - ну почему бы тебе на них не писать. Чем больше компилятор проверит, тем меньше нам тестов писать и делать ручных проверок - это же всегда хорошо было (некоторые любители clojure с этим не согласны конечно)

А почему любители clojure не согласны??

так jsники говорят) что нам не нужна система типов и строгая типизация, мы тесты пишем. Но все же чем больше возьмет на себя система типизации, тем лучше

В последнем js, в typescript есть указание типов, не просто так.

А почему любители clojure не согласны??

Это был тонки намек на UncleBob (см статью выше) - он же известный фанат clojure и тестов и против когда язык форсит писать “правильный” код