Велика сила комьюнити!

Можно еще посмотреть последние доклады от ДмитрияЖ про “кишочки” котлина - там тоже много интерестного

Можно еще посмотреть последние доклады от ДмитрияЖ про “кишочки” котлина - там тоже много интерестного

Можете ссылки скинуть?

https://youtu.be/yYG12qaxWO4

Спасибо

https://youtu.be/yYG12qaxWO4

О, а я и пропустил это, спасибо

Я правильно понимаю что kotlin подталкивает чтобы не было nullable свойств?

аааа.... а как сделать setter который this возвращает????? ОмагадОмагадОмагадОмагадОмагадОмагадОмагад

а зачем?

with(user) { name = 1 pass = 2 a = 3 }

вот тебе и fluent interface

Я бы предположил, что для Builder pattern, но у нас есть named и default arguments

И еще вопрос

Констуктор класса в котлине имеет в аргументе тип Double

Как мне это с явы то вызвать?

а в чем проблема? в джаве ж есть Double

Ну вот че то.. не подходят типы

Какой именно? примитив или обертка?

Я ошибся сигнатурой просто

примитив явы "вошел" в Double котлина без проблем

Я правильно понимаю что kotlin подталкивает чтобы не было nullable свойств?

подталкивает не то слово) пинает*

Я правильно понимаю что kotlin подталкивает чтобы не было nullable свойств?

форсит еще бы желательно val юзать повсеместно

тяжко будет... яву перевести на котлин. В половине мест - nullable

в том числе в тех же сущностях

тот же id дожлен быть nullable - т.к. при отправке в orm она должна понять создавать сущность или обновлять

тот же id дожлен быть nullable - т.к. при отправке в orm она должна понять создавать сущность или обновлять

И что такого?

ставь lateinit или Int?

если у тебя реально поле бывает null и через магию ORM сетается

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

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

!! если есть уверенность, что проверка не нужна

... выглядит как какойто костыль это !!

так и есть

я не могу воткнуть lateinit. Потому что орм проверит (очевидно) что там в id. И получится что там null и, как я понимаю, будет бобо

"Тип такого свойства должен быть non-null и не должен быть примитивным. Доступ к lateinit свойству до того, как оно проинициализировано, выбрасывает специальное исключение, которое чётко обозначает, что свойство не было определено." А у меня это String

Еще и не должно быть в конструкторе

посмотрел инфу по spring-data-kotlin. Чуваки там val пишут в свойствах...

val id: Long = -1 лол

все просто

не переводи сущности jpa на котлин

Ну как так то?

ну jpa и без котлина костыльная и убогая

А не спасет... при работе с сущностями java в котлине - все равно мучаться с nullable

эти аннотации

возьми ORM где можно нормально работать

https://www.jooq.org/ http://cayenne.apache.org/

Ну да, ща все перепилю, погоди

стоп, а зачем ты существующий код перепиливаешь?

ну... не хочу яву хочу котлин

ну пиши на котлине, зачем легаси то трогать

Ну.. это типа мое легаси

могу и трогать

плагин org.jetbrains.kotlin:kotlin-noarg - для того чтобы создавать пустой констурктор для всех @Entity

да, больше костылей, богу костылей

=)

А зачем... делать val в свойствах?

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

хорошо же

хз.. чем?

взял пачку объектов, прогнал через какую либо фию.. она все поменяла что ей надо. Дальше работаешь.

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

Я очевидно не догоняю, но вы бы объяснили в чем фишка immutability

В консистентности данных

прям недавно было: https://blog.jetbrains.com/idea/2017/08/code-smells-mutation/

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

Ну, во-первых thread-safety. Нет никаких проблем с изменением состояния и всем вот этим вот. Просто новый объект, который всегда можно читать. Во-вторых, "А тут - она вернет новый массив, а он может быть был закреплен в другом объекте - перепривязывать" говорит о том, что это построено на сайд-эффектах. А сайд-эффекты довольно мутная тема чтобы строить на них сколко-нибудь серьезные вещи.

взял пачку объектов, прогнал через какую либо фию.. она все поменяла что ей надо. Дальше работаешь.

Типикал императивное мышление (egor.jpeg)

это кстати тоже описывается в эффектив джаве которую я рекомендовал посмотреть))

профит от имутабельности

если посмотреть в сторону react и redux - можно очень быстро проверять - было ли по факту изменение данных, и соответсвенно - нужно ли запускать процесс обновления ui

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

@metalgear ну вот это и есть большой минус. Это заставляет перерисовывать (как минимум пересчитывать) дофига чего. Было бы у них реактивное хранилище - проблем бы не было.

@lllewik это как angular и его 2х сторонний биндинг?

@metalgear а я не говорил про двусторонний =) Состояние надо менять только через action)

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

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

чистота метода != иммутабельность

Я не говорил про чистоту. Ну в плане того что аргументы не поменяются - тут да, будет чистота.

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

@metalgear ну вот это и есть большой минус. Это заставляет перерисовывать (как минимум пересчитывать) дофига чего. Было бы у них реактивное хранилище - проблем бы не было.

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

ну я просто давал комментарий как еще может использоваться свойство иммутабельности, с которым познакомился именно во время работы с react + redux. зло это или добро - я не берусь судить

@metalgear именно. Не совпало - перерисовывай (пересчитывай) нафиг все. А если у меня поменялось какое то свойство всего одно и оно отвечает за флажок какой - то при реактивном хранилище перерисуется (пересчитается) только флажок а не весь контейнер

реакт разрулит такой кейс, при условии правильной организации компонентов

во... сиди организовывай компоненты

вот мне и разонравится реакт и свалил на vue

ну да, сиди организовывай)

@metalgear именно. Не совпало - перерисовывай (пересчитывай) нафиг все. А если у меня поменялось какое то свойство всего одно и оно отвечает за флажок какой - то при реактивном хранилище перерисуется (пересчитается) только флажок а не весь контейнер

советую все-же разобраться в персистентных структурах данных

Так он проверяет только по тому что reducer вернул. Или я чего не понял? Глубже оно не идет

Кстати не многие в курсе, но в котлин есть персист. коллекции https://github.com/Kotlin/kotlinx.collections.immutable

ну как есть.. это инкубатор)

Как и корутины ?

Короче, вы считаете что вот прям все структуры стоит делать immutable по умолчанию и только если потребуется - изменяемые?

Так он проверяет только по тому что reducer вернул. Или я чего не понял? Глубже оно не идет

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

Так по дефолту же коллекции иммутабельные в котлине

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

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

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

Из-за этого приходится постоянно поддерживать правильную архитектуру во время разработки. Чуть что поменялось - перепиливай компоненты, чтобы лишнего не обнволялось. Еще этот shouldComponentUpdate - как ручной привод в самом деле. Зачем этим страдать, когда dom может быть перерисован по событию изменения КУСОЧКА (<- слово пропустил) состояния?