Похоже, что из коробки нет саспендбл лейзи, никто с этими он сталкивался?

По-моему из коробки вообще нету suspend property delegates.

suspend-делегаты вообще поддерживаются?

По-моему из коробки вообще нету suspend property delegates.

Не до делегатов, лишь бы функциональность была готовая

Дык lazy ж вроде делегатом является.

Дефферед наверное можно использовать

Кстати да, можно даже async(start = CoroutineStart.LAZY) (запускается посредством .start() / `.await()`)

Дык lazy ж вроде делегатом является.

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

Кстати да, можно даже async(start = CoroutineStart.LAZY) (запускается посредством .start() / `.await()`)

Надо посмотреть

Похоже, что из коробки нет саспендбл лейзи, никто с этими он сталкивался?

Я что-то похоже эмулирую, заменой просто suspend на хранение лямбды suspend () -> T за одно ее можно и много раз юзать

lazy ж вроде как раз для того, чтобы вызывать один раз, но при первом обращении.

С lazy проблема, что в типе не понятно лази она или нет (да и то что одноразовая). Иногда нужно что-то что-то типа rx.Single

Кстати, @fogone, для более точного соответствия этому делегату надо ещё обязательно сделать context = Unconfined, дабы оно инициализировалось ровно в том потоке, откуда и было первый раз дёрнуто.

С lazy проблема, что в типе не понятно лази она или нет (да и то что одноразовая). Иногда нужно что-то что-то типа rx.Single

В типе не понятно, да. По проперти снаружи вообще трудно делать хоть какие-то предположения, что за её get() стоит.

Господа, тут никто еще не дошел до кондиции ? что бы заменить все свои ISomeNameService/ISomeNameRepository и тд (можно без I) на лямбды (UserId) -> User Ну и доп. вопрос, почему я не могу наследоваться от suspend лямбды? те так могу class DefaultService : () -> String а так нет class DefaultService : suspend () -> String

Господа, тут никто еще не дошел до кондиции ? что бы заменить все свои ISomeNameService/ISomeNameRepository и тд (можно без I) на лямбды (UserId) -> User Ну и доп. вопрос, почему я не могу наследоваться от suspend лямбды? те так могу class DefaultService : () -> String а так нет class DefaultService : suspend () -> String

> наследоваться от suspend лямбды Говорили, что допилят, и поинтересовались, зачем мне это нужно)

OK, хотя я тоже не уверен что это хорошая идея ?

OK, хотя я тоже не уверен что это хорошая идея ?

да ну, отличная идея

интерфейс с suspend-функциями же можно имплементить)

Господа, тут никто еще не дошел до кондиции ? что бы заменить все свои ISomeNameService/ISomeNameRepository и тд (можно без I) на лямбды (UserId) -> User Ну и доп. вопрос, почему я не могу наследоваться от suspend лямбды? те так могу class DefaultService : () -> String а так нет class DefaultService : suspend () -> String

зачем вообще наследоваться от лямбд? по каким тегам это искать на порнолабе?

зачем вообще наследоваться от лямбд? по каким тегам это искать на порнолабе?

Лямбда — это вид выражения, (Arg) -> Ret — это называется «функциональный тип», а от абстрактных типов как раз и наследуются.

Наш ответ Егору Бугаенко -- он из объектов делает функциональщину, а мы из функций будем делать объекты! (простите, не удержался)

Наш ответ Егору Бугаенко -- он из объектов делает функциональщину, а мы из функций будем делать объекты! (простите, не удержался)

Лол

Наш ответ Егору Бугаенко -- он из объектов делает функциональщину, а мы из функций будем делать объекты! (простите, не удержался)

Срочно в твиттер :D

Наш ответ Егору Бугаенко -- он из объектов делает функциональщину, а мы из функций будем делать объекты! (простите, не удержался)

Функции и есть объекты.

Функции и есть объекты.

А обьекты - это функции

А обьекты - это функции

Только если у них есть invoke.

@KirillTim я его боюсь, особенно после недавней недели backendsecret. @Harmonizr я, собственно, не против наследования от функций, хотя сам ещё ни одного юзкейса не видел. Просто вспомнился товарисч.

@KirillTim я его боюсь, особенно после недавней недели backendsecret. @Harmonizr я, собственно, не против наследования от функций, хотя сам ещё ни одного юзкейса не видел. Просто вспомнился товарисч.

А что там было? Или ты про ту, что Егор вёл?

А что там было? Или ты про ту, что Егор вёл?

Да, про ту.

Только если у них есть invoke.

Ну это только по конвенции котлина, в джаве полно функциональных интерфейсов с test, run, consume и т.д.

Я где то читал притчу, где мастер посылал ученика то изучать замыкания то ооп, пока тот не познал дзен

Ну это только по конвенции котлина, в джаве полно функциональных интерфейсов с test, run, consume и т.д.

Да, но какие объекты в таком случае считать функциями? Я бы сказал, что в Java лямбда-выражение или указатель на метод — объект. И всё, в одну сторону.

для бедных: ru_lambda http://ru-lambda.livejournal.com/27669.html

Да, но какие объекты в таком случае считать функциями? Я бы сказал, что в Java лямбда-выражение или указатель на метод — объект. И всё, в одну сторону.

А можно ли обьекты считать функциями?

А можно ли обьекты считать функциями?

я же ответил)

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

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

Я считаю объекты функциями, если у них есть invoke.

А что там было? Или ты про ту, что Егор вёл?

Адок там был.

Я считаю объекты функциями, если у них есть invoke.

прям джес стайл

Я считаю объекты функциями, если у них есть invoke.

Т.е. по названию метода?

Адок там был.

А можно tldr? Или обычный сексизм и прочее?

Т.е. по названию метода?

по наличию с определённым названием и оператором

А можно tldr? Или обычный сексизм и прочее?

а давайте не здесь)

а давайте не здесь)

Ок, сорри

Ок, сорри

ну, это не замечание, не упрёк, просто лучше не надо

ну, это не замечание, не упрёк, просто лучше не надо

Угу :)

А можно tldr? Или обычный сексизм и прочее?

tl:dr: всё как обычно + всё скатилось в хохлосрач. Пардон.

Касательно "функция, потому что есть invoke()" -- в плюсах такие штуки (с перегруженным operator ()) зовутся функторами. А функции -- это функции. Так что на мой взгляд объект не может быть функцией (в рамках Kotlin, офк).

Каково переходить обратно на java после kotlina?

Каково переходить обратно на java после kotlina?

Нормально

Каково переходить обратно на java после kotlina?

Pain

Нормально

А на шестёрку?

А на шестёрку?

Андроид.)

А на шестёрку?

Не пишу под андроид почти последние пол года, поэтому у меня java8 и котлин параллельно идут

а часто приходится пользовать аннотации типа @JvmStatic?

вообще зачем они?

Я тут просто конвертером воспользовался, и он такую конструкцию вставил

очень редко

в основном для вызова котлин кода из явы

ну если есть код на джаве то приходится)

У меня общий вопрос, или даже просто интересно мнение каждого: какими решениями для доступа к бд вы пользуетесь? Библиотеки/фреймворки/свои решения какие-то. Всё это в контексте Kotlin/Java конечно же. Может кто успешно переиспользует код доступа к бд между Android и Backend проектами. Интересны любые мысли по этому поводу

Не пишу под андроид почти последние пол года, поэтому у меня java8 и котлин параллельно идут

Я тоже не пишу, шестерка на сервере)

Доступ к бд - mybatis

У меня общий вопрос, или даже просто интересно мнение каждого: какими решениями для доступа к бд вы пользуетесь? Библиотеки/фреймворки/свои решения какие-то. Всё это в контексте Kotlin/Java конечно же. Может кто успешно переиспользует код доступа к бд между Android и Backend проектами. Интересны любые мысли по этому поводу

между бэком и фронтом ой ли получится переиспользовать что-то кроме DTO. Сейчас добиваю бэк, приступлю к андроиду и скорее всего разве что их и получится перенести + какую-то часть валидации. Остальное весьма специфично, и модели данных отличаются радикально Доступ к БД jOOQ, пробовал еще из плюс-минус котлиновского Ebean, но задолбался с их enchancer-ом. А так – больно уж хорош jOOQ, особенно для DB-first проектов, пока альтернатив ему не видел.

между бэком и фронтом ой ли получится переиспользовать что-то кроме DTO. Сейчас добиваю бэк, приступлю к андроиду и скорее всего разве что их и получится перенести + какую-то часть валидации. Остальное весьма специфично, и модели данных отличаются радикально Доступ к БД jOOQ, пробовал еще из плюс-минус котлиновского Ebean, но задолбался с их enchancer-ом. А так – больно уж хорош jOOQ, особенно для DB-first проектов, пока альтернатив ему не видел.

Db first ещё и Apache Cayenne, и квери тоже удобно писать. Каен больше на орм похож

Db first ещё и Apache Cayenne, и квери тоже удобно писать. Каен больше на орм похож

ORM – зло. Никогда не знаешь, чем удивит тебя очередная, если пробовать использовать поверх нее какую-нибудь модификацию.

Хм, а зачем вообще какие-то DSL обертки над эффективным DSL для работы с данными?

Хм, а зачем вообще какие-то DSL обертки над эффективным DSL для работы с данными?

Почему DSL? У меня (ладно, на андроиде, но не в этом суть) куча ORM охреневала после подключения SQLCipher, например.

Хм, а зачем вообще какие-то DSL обертки над эффективным DSL для работы с данными?

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

Ребят, а чтобы event-sourcing пощупать в Котлин, надо обязательно в akka идти? Попроще способа нет?

Ребят, а чтобы event-sourcing пощупать в Котлин, надо обязательно в akka идти? Попроще способа нет?

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

Я видимо не шарю, но там (в акке) есть еще и persistence - те с помощью этого можно вообще обходится без работы с базой напрямую. Все переодически думаю, как бы написать несложную либу (на котлине), что бы это натянуть на Android ?

Почему DSL? У меня (ладно, на андроиде, но не в этом суть) куча ORM охреневала после подключения SQLCipher, например.

В смысле, зачем удобный SQL заменять ещё какими-то поделками? Обычно не совсем корректными и менее удобными и все равно требующими знания SQL.

вообще я преследую цель избавиться от monkey job в качестве написания бойлерплейтного sql/маппинга из энтити в таблицу в обе стороны. Но при этом хотелось бы что-нибудь, что само может решить n+1 проблему или это всё мечты и нужно выбирать между этим одно?

В смысле, зачем удобный SQL заменять ещё какими-то поделками? Обычно не совсем корректными и менее удобными и все равно требующими знания SQL.

Можно тогда спросить: "Зачем делать абстракции?" Я вот не считаю что SQL удобный, но знать его приходится, потому что абстракции не идеальны. Вот у меня в ORM есть такой запрос: val candidates = ObjectSelect.query(Candidate::class.java) .where(Candidate.EMAIL.likeIgnoreCase(dbQuery)) .or(Candidate.COMPANY.likeIgnoreCase(dbQuery)) .or(Candidate.FIRST_NAME.likeIgnoreCase(dbQuery)) .or(Candidate.LAST_NAME.likeIgnoreCase(dbQuery)) .or(Candidate.PHONE.likeIgnoreCase(dbQuery)) .or(Candidate.PHONE2.likeIgnoreCase(dbQuery)) .or(Candidate.STATUS.likeIgnoreCase(dbQuery)) .or(Candidate.TAGS.dot(CandidateTag.NAME).likeIgnoreCase(dbQuery)) .offset(serviceConfiguration.pageSize * (page - 1)) .limit(serviceConfiguration.pageSize) .orderByProp(Candidate.ID_PK_COLUMN) .select(context) .map { it.toDto() } неужели он может выглядеть понятнее на SQL? как мне оформлять код, следить за типо безопасностью (и безопасностью типов :) )?

Можно тогда спросить: "Зачем делать абстракции?" Я вот не считаю что SQL удобный, но знать его приходится, потому что абстракции не идеальны. Вот у меня в ORM есть такой запрос: val candidates = ObjectSelect.query(Candidate::class.java) .where(Candidate.EMAIL.likeIgnoreCase(dbQuery)) .or(Candidate.COMPANY.likeIgnoreCase(dbQuery)) .or(Candidate.FIRST_NAME.likeIgnoreCase(dbQuery)) .or(Candidate.LAST_NAME.likeIgnoreCase(dbQuery)) .or(Candidate.PHONE.likeIgnoreCase(dbQuery)) .or(Candidate.PHONE2.likeIgnoreCase(dbQuery)) .or(Candidate.STATUS.likeIgnoreCase(dbQuery)) .or(Candidate.TAGS.dot(CandidateTag.NAME).likeIgnoreCase(dbQuery)) .offset(serviceConfiguration.pageSize * (page - 1)) .limit(serviceConfiguration.pageSize) .orderByProp(Candidate.ID_PK_COLUMN) .select(context) .map { it.toDto() } неужели он может выглядеть понятнее на SQL? как мне оформлять код, следить за типо безопасностью (и безопасностью типов :) )?

Я предпочитаю во вьюшки выносить максимально такую штуку или в хранимки. Ибо даже с DSL выглядит как [ну вы сами поняли что]

Можно тогда спросить: "Зачем делать абстракции?" Я вот не считаю что SQL удобный, но знать его приходится, потому что абстракции не идеальны. Вот у меня в ORM есть такой запрос: val candidates = ObjectSelect.query(Candidate::class.java) .where(Candidate.EMAIL.likeIgnoreCase(dbQuery)) .or(Candidate.COMPANY.likeIgnoreCase(dbQuery)) .or(Candidate.FIRST_NAME.likeIgnoreCase(dbQuery)) .or(Candidate.LAST_NAME.likeIgnoreCase(dbQuery)) .or(Candidate.PHONE.likeIgnoreCase(dbQuery)) .or(Candidate.PHONE2.likeIgnoreCase(dbQuery)) .or(Candidate.STATUS.likeIgnoreCase(dbQuery)) .or(Candidate.TAGS.dot(CandidateTag.NAME).likeIgnoreCase(dbQuery)) .offset(serviceConfiguration.pageSize * (page - 1)) .limit(serviceConfiguration.pageSize) .orderByProp(Candidate.ID_PK_COLUMN) .select(context) .map { it.toDto() } неужели он может выглядеть понятнее на SQL? как мне оформлять код, следить за типо безопасностью (и безопасностью типов :) )?

А что думаешь насчет hibernate? Там же вроде работа как с коллекциями

Я предпочитаю во вьюшки выносить максимально такую штуку или в хранимки. Ибо даже с DSL выглядит как [ну вы сами поняли что]

Конкретно этот кусок я планирую на full text search переписать, это для MVP кусок был)

Конкретно этот кусок я планирую на full text search переписать, это для MVP кусок был)

Судя по page -1 он где-то около роутов?)

Судя по page -1 он где-то около роутов?)

нет, page просто параметр

А что думаешь насчет hibernate? Там же вроде работа как с коллекциями

Хибер не люблю, не практикую. Мне всяко ближе jooq, cayenne, mybatis (Для справки я писал несколько больших приложений с хибером, и он понятное дело большую часть времени работает, но работать с ним совсем не нравится)

да даже jdbc template кажется лучше

Я предпочитаю во вьюшки выносить максимально такую штуку или в хранимки. Ибо даже с DSL выглядит как [ну вы сами поняли что]

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

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

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