Rethinking of chimney for scala 3

[wookievx]

Prelude

My attempt at migrating chimney to Scala 3 was quite a big effort, learning Scala 3 meta-programming. My initial goal was to work almost exclusively with highest level meta-programming constructs: Mirrors and inline, and unfortunately this approach turned out to be limited, as combining smaller pieces of code into larger ones and creating abstractions proved problematic. I resorted in some places to next level of meta-programming, macros (sometimes necessary for accessing method names, etc.).

Main problems as of right now

• Implementation is a bit of a mess right now and while inline is working for most cases I had to replace it on the top-level with macros to somehow glue together different parts of derivation logic.
• Implementation is somewhat inefficient (both compilation and runtime performance of generated code). Regarding the latter it is a complex issue, for example I am using methods returning full transformers when recursively deriving transformers and patchers, so on each level of class hierarchy a lot of anonymous classes could be generated, which results in larger byte-code sizes and a lot of virtual dispatches in simple cases that will never be optimized by JVM. This issue could be mitigated by exposing some top-level method like:

  inline def transform[From, To](from: From): To = ??? //internally handles all the different cases, dispatching derivation to dedicated logic

  This way generated code should be close to optimal hand-written implementation, barring some occasional boxing of value types.

[guersam]

How is it bad compared to scala 2 implementation? I think there's further room for improvement once we get initial feature parity with current codebase so that more people be able to migrate to Scala 3.

[guersam]

FYI, during this holiday weekend I managed to add some of missing features such as Unit, Left, Right, and enableUnsafeOption: https://github.com/guersam/chimney/commits/scala3

[kjh618]

The original Scala 2 implementation seems to generate quite efficient code, calling the destination type constructor directly with the source fields inlined. I tried mimicing that behavior with Mirrors, but that seems quite difficult (or impossible?) as you cannot call the constructor directly and have to use fromProduct, and it's hard to avoid nested tuples.

I made a new PoC implementation using the new Scala 3 compile-time reflection API that generates code similar to the Scala 2 version: https://github.com/kjh618/chimney/tree/chimney3-reflection. Currently it implements Transformer/TransformerDefinition, withFieldConst, and automatic derivation for case classes only.

I think going in this direction might be more beneficial, as reflection allows for more flexibility that's helpful for implementing complex trasformer derivation logic. (The Scala 2 version uses compile-time reflection quite heavilty too.) What do you think?

[aprakash-work]

do you happen to have any updates here? I would love to use this library in my project, but don't want to be tied to 2.x

[wookievx]

I am working on library in my spare time, I am not sure if I want to provide cross compilation as there is very little of the library to be shared between scala 2.13 and scala 3 (transformer and patcher) definition. I am also changing Patcher to be derived recursively for nested fields (to provide typesafe and efficient json merge like semantics). Current progress of my work can be found here: https://github.com/wookievx/chimney/pull/2. I need to fix some issues regarding coproduct derivation, error reporting, rewrite patcher to use similar approach to transformers. All the help is welcome (I might merge linked PR soon)

wt., 23 sie 2022 o 16:51 aprakash-work @.***> napisał(a):

do you happen to have any updates here? I would love to use this library in my project, but don't want to be tied to 2.x

— Reply to this email directly, view it on GitHub https://github.com/wookievx/chimney/issues/5#issuecomment-1224186888, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACYU2DZXDUT4WMXFVQ6VEC3V2TQP3ANCNFSM5KVTCKEQ . You are receiving this because you authored the thread.Message ID: @.***>