return в начале метода как бы указывает что у тебя метод помимо проведения полезной работы занимается чем нибудь еще побочным (например, проверяет валидность входных данных)

такое сложнее тестировать и должно было умереть с поддержкой Nullable типов

не делай ретерн - кидай эксепшны )))

не делай ретерн - кидай эксепшны )))

опередил :)

не следуют контракту - мочи сразу

не делай ретерн - кидай эксепшны )))

require же есть ?

а это где-то прописано? в kotlin style guides я не заметил...

Языку они не нужны. Кроме того идея сама подсказывает строки, которые возвращают значения, но если тело лямбды не линейное, я рекомендую писать. Иначе текст без IDE становится нечитаемым.

Теоретики из них хорошие, никто не спорит. Да только в реальном мире не всегда все идеально по учебнику идёт.

Все подобные рекомендации родились из практики либо прикладной математики, либо программирования, если между ними вообще есть разница.

Языку они не нужны. Кроме того идея сама подсказывает строки, которые возвращают значения, но если тело лямбды не линейное, я рекомендую писать. Иначе текст без IDE становится нечитаемым.

Нужны ли лямбды с нелинейным телом? :)

Все подобные рекомендации родились из практики либо прикладной математики, либо программирования, если между ними вообще есть разница.

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

Чёрный ящик с одним входом, одним выходом и без побочных эффектов проще всего тестировать. Поэтому и есть такая рекомендация. Не совсем понимаю, что в этом плане поменялось в логике, что она устарела.

Аналогия с черным ящиком неуместна, т/к выход то у него всего один ) На то он и черный

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

А что, в предыдущих годах был идеальный мир?

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

Практика показывает что сейчас как раз тренд на заимствование фич из ФП, где как раз 1 вход всегда 1 выход

Теоретики из них хорошие, никто не спорит. Да только в реальном мире не всегда все идеально по учебнику идёт.

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

Практика показывает что сейчас как раз тренд на заимствование фич из ФП, где как раз 1 вход всегда 1 выход

hype-driven development :/

hype-driven development :/

Ну хоть не как жаваскрипте год назад)

А что, в предыдущих годах был идеальный мир?

Нет, но системы были намного проще.

маргарет гамильтон с тобой не совсем согласна

Аналогия с черным ящиком неуместна, т/к выход то у него всего один ) На то он и черный

Это не аналогия. Это пример того, какие конструкции проще всего тестировать.

Практика показывает что сейчас как раз тренд на заимствование фич из ФП, где как раз 1 вход всегда 1 выход

Я думал он закончился пару лет назад ?

Я думал он закончился пару лет назад ?

То-то сейчас фича реквесты на тайпклассы и ньютайпы в котлине)

Это не аналогия. Это пример того, какие конструкции проще всего тестировать.

Тогда при чем здесь черный ящик? https://en.wikipedia.org/wiki/Gray_box_testing

И всякие arrowKt

Я думал он закончился пару лет назад ?

Это почему же? У нас Big Data все забросили?

а какие щас ваще тренды?

То-то сейчас фича реквесты на тайпклассы и ньютайпы в котлине)

Котлин вообще новый языке, а в жс/джаве тренд уже кончился

Тогда при чем здесь черный ящик? https://en.wikipedia.org/wiki/Gray_box_testing

При том, что если каждая лямбда и каждый метод будут снаружи представимы в виде этой абстракции, то их будет проще тестировать.

Котлин вообще новый языке, а в жс/джаве тренд уже кончился

То-то в джаве пилят project Valhalla, и один из дизайнеров языка активно обсуждает, как в него добавить value types и data classes

Это почему же? У нас Big Data все забросили?

На котлине? Да вроде даже не начинали.

При том, что если каждая лямбда и каждый метод будут снаружи представимы в виде этой абстракции, то их будет проще тестировать.

Это трюизм, я всего лишь заметил, что упоминание черного ящика неудачно и противоречит концепции тестирования черного ящика. В бутылку лезть не буду, т/к согласен во всем.

То-то в джаве пилят project Valhalla, и один из дизайнеров языка активно обсуждает, как в него добавить value types и data classes

Это они уже лет 10 пытаются (и ещё 10 будут)

На котлине? Да вроде даже не начинали.

Не на котлине, а вообще. Ну а насчёт тренда в сторону ФП - я лично вообще не представляю, как ООП язык может не поддерживать ФП, если с точки зрения таксономии парадигм программирования, ООП является расширением ФП концепциями явного инкапсулированного состояния и наследования.

Есть у меня кода кусок: fun getMainComponent(): MainComponent { if (mainComponent == null) { mainComponent = getAppComponent().mainComponentBuilder().build() } return mainComponent!! } Переписываю на вот это: fun getMainComponent(): MainComponent = mainComponent ?: getAppComponent().mainComponentBuilder().build().also { mainComponent = it } Код по-прежнему не нравится и могу придумать, как это обобщить. Есть идеи?

Есть у меня кода кусок: fun getMainComponent(): MainComponent { if (mainComponent == null) { mainComponent = getAppComponent().mainComponentBuilder().build() } return mainComponent!! } Переписываю на вот это: fun getMainComponent(): MainComponent = mainComponent ?: getAppComponent().mainComponentBuilder().build().also { mainComponent = it } Код по-прежнему не нравится и могу придумать, как это обобщить. Есть идеи?

mainComponent - это такое lazy property?

> .also { mainComponent = it } ?

Есть у меня кода кусок: fun getMainComponent(): MainComponent { if (mainComponent == null) { mainComponent = getAppComponent().mainComponentBuilder().build() } return mainComponent!! } Переписываю на вот это: fun getMainComponent(): MainComponent = mainComponent ?: getAppComponent().mainComponentBuilder().build().also { mainComponent = it } Код по-прежнему не нравится и могу придумать, как это обобщить. Есть идеи?

такое и не должно нравиться

код, который делает концептуально неправильные вещи, не должен выглядеть красиво

Нет. My bad, забыл важную вещь: Так объявлено свойство: private var mainComponent: MainComponent? = null Так оно сбрасывается fun destroyMainComponent() { mainComponent = null }

код, который делает концептуально неправильные вещи, не должен выглядеть красиво

Слышь, парень, не хочешь немного андроида?

забавно

Слышь, парень, не хочешь немного андроида?

я отбился от него всевозможными костылями и избавился от такого

он админ в андроид канале

хаха

как-то безрадостно

Нет. My bad, забыл важную вещь: Так объявлено свойство: private var mainComponent: MainComponent? = null Так оно сбрасывается fun destroyMainComponent() { mainComponent = null }

а зачем его ресетить

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

Это кусок класса дерева компонентов приложения (Андроид, естессно). Новый можно создавать только если старый явно сбросили.

На джаве это выглядело ОК, а вот на котлине не покидает ощущение, ччто можно сделать лучше

самописный di что ли

yep

Это кусок класса дерева компонентов приложения (Андроид, естессно). Новый можно создавать только если старый явно сбросили.

вынеси getAppComponent().mainComponentBuilder().build() .also { mainComponent = it } это в отдельный метод

и дергай его

Слабовато. У меня таких компонетнов штук 10

Думаю, что эту логику надо в отдельный тип завернуть

вынеси куда-нибудь все это

да...

альтернативный метод как сделать красиво - юзать di-либки )))

fun getMainComponent(): MainComponent = mainComponent ?: init() fun init(): MainComponent = getAppComponent().mainComponentBuilder().build() .also { mainComponent = it }

сук

за тебя там все эти ужасы написали другие люди

поломалось чутка

алсо оч криво смотрится

public val mainComponent by lazy { getAppComponent() .mainComponentBuilder() .build() }

вообще не о том

его же загулять надо

Сам спросил, сам отвечу: class Component<T>(private val builder: () -> T) { private var instance: T? = null fun getInstance() = instance ?: builder().also { instance = it } fun destroy(){ instance = null } } Ну и пропертя: private var mainComponent = Component<MainComponent>({ getAppComponent().mainComponentBuilder().build() }) Норм?

ERROR: S client not available

из-за неявного Create и явного Destroy красота теряется

это делегат?

нет, пока просто тип.

напиши в джавовом стиле

if (instance == null) instance = builder() return instance

в getInstance

так приятнее

глазам

getInstance не nullbale должон быть

instance!!

instance!!

Это еще хуже смотрится

instance!!

Вот с этого все и началось))

эстэты)

его же загулять надо

Ок, я в ваш монастырь лишь раз мельком заглянул, ужаснулся пляскам вокруг жизненного цикла и странной терминологии и убежал. Но неужели нельзя абстрагироваться от всей этой бани с var whatever: Type?. Например если уж так _надо_ зануляться, то дропать с корня.

поясни

поясни

Почему андроид разрабы форсят var mainComponent (c сопутствующей болью), вместо val mainComponent ?

занулить надо ссылки

занулить надо ссылки

А занулять удаляя объект, содержащий cсылки (mainComponent) - не вариант?

Почему андроид разрабы форсят var mainComponent (c сопутствующей болью), вместо val mainComponent ?

Это уже детали) Над ним есть AppComponent, он вечен

занулить надо ссылки

зачем?

Кстати, а вы заметили, к каким извращениям приходится прибегать, чтобы дать понять, что вы задаёте вопрос, а не Nullable тип?

Прошу прощения

тип ?

Кстати, а вы заметили, к каким извращениям приходится прибегать, чтобы дать понять, что вы задаёте вопрос, а не Nullable тип?

Nothing?? :)

Кстати, а вы заметили, к каким извращениям приходится прибегать, чтобы дать понять, что вы задаёте вопрос, а не Nullable тип?

¿Нужно написать пропосал по использованию испанского перевернутого вопроса?

зачем?

это вопрос к Aleksey , я так понимаю он с ЖЦ борется

он на него ответил)

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

вообще котлин гораздо медленнее в идее обрабатывается

это фиксится железом

нет

тут точно все ок