добавь

беда

Новый выпуск https://mailchi.mp/softwaremill/scala-times-issue-2607905?e=e642d805da

А зачем ты эт сюда постишь? У них ж рассылка есть

Поручик с Наташей Ростовой плывут на лодке. - Наташа, а вас случайно веслом по голове не били? - Да что вы себе позволяете, поручик!? - Да это же я так, разговор поддержать!

(ц)

Новый выпуск https://mailchi.mp/softwaremill/scala-times-issue-2607905?e=e642d805da

e=e642d805da это твой айди в ссылке. По ней можно отписать тебя от рассылки или сменить Мейл.

)))))

А зачем ты эт сюда постишь? У них ж рассылка есть

популизирую

А когда 43 выпуск скалалаза будет в подкастах тунца?

@nikitamatveenko сегодня планируем выложить

@nikitamatveenko сегодня планируем выложить

Спасибо!!

а что за подкасты тунца?)

а что за подкасты тунца?)

ай тьюнс в народе тунец зовется

https://github.com/RBMHTechnology/eventuate юзал кто?

Rbmk ток юзал

Ковырял

https://github.com/RBMHTechnology/eventuate юзал кто?

я тоже ковырял интересная штука там есть пример как поднять 5 нод но crdt весьма ограничена по возможному функционалу - для прода придется реальномного допиливать ну конечно зависит от задачи

и он же почти перестал ее пилить

Всем привет. У меня был некоторый List[_], после вызова map я получил List[(_, _)], при этом мне нужен Map[_, _]. Что в данной ситуации будет лучше, вызвать .toMap или breakOut передать?

view -> map -> toMap

breakOut deprecated считай

breakOut deprecated считай

а можно по подробней, почему "считай"?

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

в строумене?

https://scala-lang.org/blog/2017/02/28/collections-rework.html

ищи breakOut (там несколько вхождений)

?

Спасибо, про view я благополучно забыл

https://scala-lang.org/blog/2017/02/28/collections-rework.html

Судя по всему таких забывших немало

а scalafix этот breakOut фиксит?

глупо выйдет, если нет

а scalafix этот breakOut фиксит?

надо смотреть, отдельного описания по правилам вродь нет

А как он его пофиксит? Там каждый случай уникален. Врядли там обученную нейронную сеть встроят.

знатоки макросов и прочих шаплесов, подскажите, есть ли какие-то непреодолимые преграды в написании макроса, который выведет Circe Encoder для голого трэйта?

знатоки макросов и прочих шаплесов, подскажите, есть ли какие-то непреодолимые преграды в написании макроса, который выведет Circe Encoder для голого трэйта?

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

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

не про силд, а зачем знать это? Есть trait { def name: String def age: Int } например

знатоки макросов и прочих шаплесов, подскажите, есть ли какие-то непреодолимые преграды в написании макроса, который выведет Circe Encoder для голого трэйта?

Макрос для не sealed не знает наследников

зачем нужны наследники, мне же их создавать не надо, речь про Encoder (trait -> JSON)

не про силд, а зачем знать это? Есть trait { def name: String def age: Int } например

Ну написать макрос которые для def нагенерит Encoder не сложно

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

не про силд, а зачем знать это? Есть trait { def name: String def age: Int } например

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

все def в трэйте подлежат сериализации, как все поля в case class сейчас

все def в трэйте подлежат сериализации, как все поля в case class сейчас

нет преград для такого костыля)

почему ты называешь это костылём?

почему ты называешь это костылём?

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

а через semanticdb можно откопать наследников незапечатанного трейта?

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

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

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

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

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

Знаю я тут одну либу где можно без копирования в аст писать json ?

levsha?

levsha?

Та не

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

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

а через semanticdb можно откопать наследников незапечатанного трейта?

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

Если уж вам жалко памяти даже на копирования в case class, то я для этого и писал https://github.com/tethys-json/tethys

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

можно влепить новую фазу в процесс компиляции?

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

можно влепить новую фазу в процесс компиляции?

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

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

addCompilerPlugin("slow_scala_compiler_twice_more")

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

тот случай, когда можно два раза войти в одну и ту же реку, но зачем?

но вообще это жесткий костыль :)

addCompilerPlugin("slow_scala_compiler_twice_more")

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

ERROR: S client not available

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

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

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

Есть модуль common-model с трэйтом UserLike, он отдаётся из сервисов, которые внутри используют его реализацию User недоступную вызывающим - чтобы такие классы не попали в JSON, т.е. чтобы JSON модели были независимы от внутренней модели и легко можно было понять, если API меняется. В контроллерах такие трэйты копируем в соотв. UserJson модели и их уже сериализуем. Любопытно, можно ли избежать этого копирования, но при этом сохранить разделение JSON и внутренней модели. Если начать энкодить трэйт напрямую, то это условие не выполняется...

скаламета как раз так и делает

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

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

Есть модуль common-model с трэйтом UserLike, он отдаётся из сервисов, которые внутри используют его реализацию User недоступную вызывающим - чтобы такие классы не попали в JSON, т.е. чтобы JSON модели были независимы от внутренней модели и легко можно было понять, если API меняется. В контроллерах такие трэйты копируем в соотв. UserJson модели и их уже сериализуем. Любопытно, можно ли избежать этого копирования, но при этом сохранить разделение JSON и внутренней модели. Если начать энкодить трэйт напрямую, то это условие не выполняется...

Generic для трейта не даст его поля?

Generic для трейта не даст его поля?

что есть поле у трейта?

что есть поле у трейта?

Ну понятно же что у него специфический кейс

Ну понятно же что у него специфический кейс

это вопрос Николаю, что должен по его мнению генерик отдать)

И он сам решает какие трейты подходят

трэйты в скале перегружены сильно, в моём случе речь про что-то типа "pure trait" (no implementation, just defs/vals)

это вопрос Николаю, что должен по его мнению генерик отдать)

мне нужны def трэйта и его предков

мне нужны def трэйта и его предков

Пиши для этого точно нет никаких препятствий

Пиши для этого точно нет никаких препятствий

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

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

Это будущее придёт еще не скоро, так чтоооо

мне нужны def трэйта и его предков

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

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

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

да, про поле в трейте - имелось в виду def name: String - то есть def без параметров, который возвращает что-то, не Unit

@tvaroh не проще ли для такого трейта руками написать encoder-ы? или это очень частый кейс?

@tvaroh не проще ли для такого трейта руками написать encoder-ы? или это очень частый кейс?

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

хочется избавиться от прослойки dto?

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

хочется избавиться от прослойки dto?

хочется избавиться от необходимости во всех контроллерах делать это копирование, писать код в смысле, память вторична в целом, не хай лод... Но если убрать JSON модели в виде case class-ов, то независмость JSON теряется, непрозрачно. В общем пока прикидываю...

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

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

Есть модуль common-model с трэйтом UserLike, он отдаётся из сервисов, которые внутри используют его реализацию User недоступную вызывающим - чтобы такие классы не попали в JSON, т.е. чтобы JSON модели были независимы от внутренней модели и легко можно было понять, если API меняется. В контроллерах такие трэйты копируем в соотв. UserJson модели и их уже сериализуем. Любопытно, можно ли избежать этого копирования, но при этом сохранить разделение JSON и внутренней модели. Если начать энкодить трэйт напрямую, то это условие не выполняется...

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

скрывать полностью реализации UserLike - тоже ушел давно от подобного, но если вдруг шибко понадобилось - то предпочел бы сделать ему .toPublicModel = return case class Model

скрывать полностью реализации UserLike - тоже ушел давно от подобного, но если вдруг шибко понадобилось - то предпочел бы сделать ему .toPublicModel = return case class Model

разделение моделей ещё нужно потому, что у нас каждый микросервис предоставляет код клиента к себе и он зависит только от JSON моделей и коммон (где трэйты), чтобы потроха сервисов и т.п. не лезло в класпас при пользовании клиентов. Ну нам нравится, вроде кайфик

разделение моделей ещё нужно потому, что у нас каждый микросервис предоставляет код клиента к себе и он зависит только от JSON моделей и коммон (где трэйты), чтобы потроха сервисов и т.п. не лезло в класпас при пользовании клиентов. Ну нам нравится, вроде кайфик

Ну нам нравится - это хорошо, когда нравится и стакан на половину полон) кому костыли, а кому ходули) но если я правильно понял и продолжать лениться - можно также требовать от клиентов модельки в собственных кейс-классах. а как они там у себя это дело будут делать oneMicroServiceToRuleThemAll(case class MyPrivateUser(bla...., userLike:UserLike).userLike) или использовать автоконвертацию между моделями их внутренних моделей в модели общей либы или еще как-то. - уже без разницы. в этом русле - будет погибче и сторонние сервисы, модели в которых написаны по своим правилам и которые не изменить - проще будет связать через эти клиенты. но это так - мысли в слух)

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

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

когда микросервис A использует клиент микросервиса B со всем его JSON моделями, то эти модели не текут в модели A, там обратное преобразование из JSON моделей во внутренние A

когда микросервис A использует клиент микросервиса B со всем его JSON моделями, то эти модели не текут в модели A, там обратное преобразование из JSON моделей во внутренние A

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