По факту он имеет смысл только в клиентских приложениях.

клиенсткое != мобильное

А на Kotlin нельзя писать клиентские приложения?

это таки чаще всего Android

Не раз уже такое предложение поступало, вот и решили попробовать. Я и не рассчитывал что за день эти чаты наберут по 1000 человек и так тоже будет такое активное обсуждение. Это скорее долгосрочная перспектива - пока люди привыкнут, пока аудитория у чатов наберется. Несколько месяцев.

проблема в том что насильно туда отправляют)

какой профит от этого получится?

См. разделение на Android, JVM и Android Architecture. Разделение иметь смысл может. Просто не в этом случае (по крайней мере пока).

это таки чаще всего Android

Ну всё теперь, народ, который пишет гуй на JVM идёт нах^W в Android-чат (ЩИТО?!). Большинство != все

какой профит от этого получится?

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

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

Ну всё теперь, народ, который пишет гуй на JVM идёт нах^W в Android-чат (ЩИТО?!). Большинство != все

большинство конфигов прогарда для андроида — андроид-специфичны

большинство конфигов прогарда для андроида — андроид-специфичны

Большинство != все [2] Полагаю, что корутины можно использовать с JavaFX. Я понял мысль, и в данном случае как раз был Android вопрос, но он как раз не из тех, которые можно назвать строго Android-вопросами, ибо ответ может быть применим к другим платформам (частично или полностью).

Чет не могу нагуглить ответ на вопрос, как в Kotlin указать generic тип с массивом внутри, в rxJava2 есть Consumer<Object[]> в Kotlin это Consumer<Any и тут что указать> ?

Чет не могу нагуглить ответ на вопрос, как в Kotlin указать generic тип с массивом внутри, в rxJava2 есть Consumer<Object[]> в Kotlin это Consumer<Any и тут что указать> ?

Consumer<List<Any»?

Consumer<Array<Any>> по идее

точно же спасибо

да и не ужели вам не интересно почитать обсуждение немного платформо-специфичный воспросов?

вот я люблю и про котлинJs послушать, и про бекенд

хоть ни то, ни то не шарю

все холивар утих уже

ты опоздал

видимо да

или ушел в другой чатик

еще один

@kotlin_chat_holywar

в студии или идее есть генератор для котлиновских билдеров?

котлиновские билдеры?

агамс, та любой на самом деле

дефолтная тулза Replace constructor with builder не срабатывает

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

плохой вопрос

именнованые параметры совсем не то

разве? .withMyParam(param) - java myParam = param - kotlin

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

что и дает билдер

Можно делать для этого немутабельный интерфейс + мутабльный класс

давайте поможем вам зарефакторить код? ?

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

Можно делать для этого немутабельный интерфейс + мутабльный класс

выглядит сложнее обычного билдера

а что плохого в билдере?

Наследование и билдеры это ад

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

у меня обжект на 15 полей которые должны пройти валидацию перед сетом

Наследование и билдеры это ад

+1 !!!

билдеры в котлине нужны примерно так же как и ;

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

Наследование и билдеры это ад

действительно не вижу в билдерах никакого зла, если они решают свою задачу

а наследование просто ограничивает, но опять же, для решения задач подходит

билдеры в котлине нужны примерно так же как и ;

не понимаю почему

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

потому что есть дефолтные параметры

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

а что плохого в билдере?

если я правильно понял ваш кейс то минус будет в мутабельности объекта. т.е Hren.Builder builder = Hren.newBuilder(); Hren hren = builder .setParam("one") .build(); assert hren.getParam().equals("one"); // true builder.setParam("two"); assert hren.getParam().equals("one"); // false

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

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

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

class Builder(val constValue) { var bla1 var bla2 }?

потому что есть дефолтные параметры

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

ну делай их нулами

а билдер чем тут поможет?)

и как валидация связана с билдером то?

А еще синтаксически билдеры менее удобны чем ДСЛ

билдеры вообще отстой

набросились ?

ну делай их нулами

отличный совет, язык ведь форсит нал сейфти

да ты сам странный кейс какой то сказал

что дефолтные значения какие то невалидные

ладно, поподробнее опишу, может смотрю куда-то не туда

как это билдером решать?

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

возможно не самое прямое решение на уровне валидации, но пока остановился на этом

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

ну типо интерфейс валидатор,куча имлементаций + композитный

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

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

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

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

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

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

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

Есть тут подход один,не юзать onError :)

а очень хорошо упарываться по типам

А это как? Either?

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

Делай просто объект с мутабельными полями, и для него интерфейс который с val

И не нужны билдеры при таком подходе

Делай просто объект с мутабельными полями, и для него интерфейс который с val

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

Ну смотря как ты валидацию делаешь

Есть тут подход один,не юзать onError :)

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

А это как? Either?

можно так,а можно sealed класс в двумя/n дата классами внутри, каждый описывает кейс какой-то,например: валидный объект, невалидное имя, невалидный пароль и тд

Ну смотря как ты валидацию делаешь

сейчас поочередно проверяется каждое поле, т.е. после валидации первого поля у меня будет создан объект с 1 валидным полем и 14 дефолтными с таким подходом

Ладно, положил на стек, буду за компом покажу что я имею ввиду

сейчас поочередно проверяется каждое поле, т.е. после валидации первого поля у меня будет создан объект с 1 валидным полем и 14 дефолтными с таким подходом

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

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

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

т.е. билдер выступает холдером уже сконвертированных данных

можно так,а можно sealed класс в двумя/n дата классами внутри, каждый описывает кейс какой-то,например: валидный объект, невалидное имя, невалидный пароль и тд

Ну как-то слишком необобщенно)), можно сделать generic Either/Result (так же через sealed) и в ошибку передавать enum с типами ошибками

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

если вам просто важно либо Success,либо Failure,то и Either зайдет со своим left,right

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

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

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

та не уверен честно говоря что хочу тут юзать rx, но спасибо

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

Что думаешь?

как котлин?:) хорош?)

Да

с пивком пойдет