а есть какой-то способ подружить newtype с автогенерацией в avro?
https://scastie.scala-lang.org/FpMeAVTKRDO9lewSPQRQrA

да, посмотри на Coercible https://github.com/estatico/scala-newtype#automatically-deriving-instances

пример: https://scastie.scala-lang.org/pomadchin/3sIqzcCLQMqHJWIiX4OX6Q/2

то что надо, спасибо

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

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

Народ, вопросец на ночь на счет тестов для кода с side-effect-ми.

Есть такая функция:

def handle[F[_]: Monad](
  toDB: String => F[Unit],
  toKafka: String => F[Unit],
  toLog: String => F[Unit]
): String => F[Unit] = { in =>
  toDb(in) >> toKafka(in) >> toLog(in)
}

Нужно гарантировать последовательность вызовов:
1: toDb
2: toKafka
3: toLog

Текущий подход заглючается в использовании scalamock и создании mockFunction для каждой функции-аргумента и последующей проверки вызовов.
Но вот интересно, если какие-нть "более ФП-шные" аналоги scalamock?
Проблема со scalamock в том, что у него есть implicit mutable state, который считает вызовы моков. И всё это привязано жизн. циклу тест-кейсов в scalatest.
С этим возникают проблемы при использовании scalacheck когда моки создаются/вызываются много раз внутри одного тест-кейса.

def handle[F[_]: Monad](
  toDB: String => F[Unit],
  toKafka: String => F[Unit],
  toLog: String => F[Unit]
): String => F[Unit] = { in =>
  toDb(in) >> toKafka(in) >> toLog(in)
}

Можно подобным образом переписать, как вариант:
https://scastie.scala-lang.org/DoSOfRedRiver/YQdVnjYCT22oLvnuCFZp2Q/1

В целом идея прикольная.
Но боюсь что люди меня не поймут, если я так сделаю 😅

Ну тогда можно просто функции подменять на что-то тестовое.

Вообще была идея юзать State/StateT в качестве тестового эффекта и накапливать там вызовы функций.
Проблема с таким подходом - оч. много кода в тестах по сравнению с scalamock.

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

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

Как раз недавно использовал State для похожего теста. Мне понравилось.

Вопрос: а если так уж надо гарантировать, то может лучше без тестов гарантировать на уровне типов? Чтобы нельзя было вызвать в неправильном порядке? Ну типа чтобы вызов toKafka можно было сделать только на том что _уже_ вызвало toDb?

Подскажите плез, есть два типа: IO1[_] и IO2[_]
как убедить конпелятор, что IO2 можно подставлять вместо IO1, но не наоборот?

чтобы можно было делать вот так:
first: IO1[Unit]
second: IO2[Unit]
first >> second


пробовал:
- в сигнатуре IO2[t] <: IO1[t]
- implicit ev ev: Q ~> M
- implicit ev ev: Q <:< M
- trait AutoTransform[F[_], G[_]] {
 implicit def transform[T](ft: F[T]): G[T]
}

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

Возможно у кого-нибудь будут идеи как это сделать лучше

Наследование не пробовали? Типа как в cats?

trait Query[F[_]]
trait Mutable[F[_]] extends Query[F]
implicit val io1Query: Query[IO1] = ???
implicit val io2Mutable: Mutable[IO2] = ???

тогда не совсем понятно как быть с инстансами Monad и т.д., я же комбинирую IO1 и IO2, а не Query и Mutable

trait Query[F[_]] extends Monad[F]?