Chimney VS chimney

But yeah, I wonder if using a tool for case classes conversion like https://github.com/scalalandio/chimney would help in managing those ADT hierarchies for DB/business logic/web layer/etc.

Hello, if you have some nice examples could you please check if it's something that would fit any of issues planned for 0.7.1 or create a new one?

Perhaps, https://github.com/scalalandio/chimney would leverage it.

Thankfully, there are some solutions that can help reduce the boilerplate of these manual conversions. For instance, chimney : https://scalalandio.github.io/chimney/

I want to upgrade one project to Scala 3.1, but I'm using the macro heavy chimney (https://github.com/scalalandio/chimney) to reduce the boilerplate, which is not available for Scala 3 yet. My idea was to copy and paste the code that chimney generates on 2.13, and after that uncomment the uses of chimney for now.

In my $dayjob we originally used Scala, but I pushed for a couple of new services to be written in TypeScript/Node as it was really hard to hire Scala developers. I'd say it worked well, we even took a somewhat functional approach to building things. We tried fp-ts but that was a bit hardcore (when you are trying to hire TypeScript developers who don't know functional programming), so just built Either and Option types which provided 99% of what we needed.

There are still a few things I miss though:

* Pattern matching and exhaustive checking. Using a switch statement it is possible to define a function that can emulate the compile-time exhaustive checking, but it's still rather weak compared to what you can do in Scala.

* Implicits. Being able to define something that can convert say a UUID to a String or vice versa automatically just feels like magic, especially when dealing with data from third party systems.

* Compiler macros and metaprogramming. It enables tools like Chimney (https://scalalandio.github.io/chimney/) to be built, which I don't think are possible with TypeScript right now.

Converting between these classes can add some boilerplate, but luckily there are libraries like https://github.com/scalalandio/chimney that make it much easier.

You can check out this file for example, I am building "a record" at compile time with information about fields, etc. inside of the tuple. Using that in derivation code I am able to customize the logic (based purely on the type): https://github.com/wookievx/chimney/blob/chimney3/chimney3/src/main/scala/io/scalaland/chimney/dsl/TransformerDefinition.scala

Well I managed to workaround bugs I encountered, here is the current version: https://github.com/wookievx/chimney/tree/chimney3 I am not aiming at full feature parity (I have already added some functionality to patchers I deemed useful and easy to implement, while not bothering for now to handle java beans, which would require diving deep into tasty reflection). I am not sure what to do about value classes, given opaque types are a thing. I am currently in process of migrating tests (patcher dsl and transformer dsl have somewhat extensive tests).