Currently in a lot of of places we use ctx.runtimeDataStore(idx) directly, while TransformerConfiguration's overrides store only idx.
We could move this extraction to TransformerOverrides, so that the code would NOT hardcode how we are storing/parsing runtime information.
TransformerOverrides would store overrideExpr: Expr[Any] instead of index: Int
this overrideExpr could be computed in TransformerConfiguration.readTransformerConfiguration
every usage of ctx.runtimeDataStore(idx) could be replaced with overrideExpr
This way, in the future we could:
provide an alternative API without any runtime overhead:
// no overhead for building Vector and extracting values from it
foo.transform[Bar](
Const(_.a.b.c, value),
Computed(_.d.e.f, foo => anotherValue)
)
(By alternative I am thinking a separate module or even a separate library - to avoid confusion from one-in-one API - import dsl.* - and API split into components - auto.* + inlined.* + syntax.* - and then yet another API for inlined expressions without fluent API overhead like Ducktape's.)
open up possibilities to reuse macros to provide e.g. lens-like functionality
// already possible!
(foo: Foo).into[Foo].withFieldConst(_.bar.baz, value).transform
// could be possible to implement
foo.updateInline(
Const(_.bar.baz, value)
)
(If we'd compare to e.g. Quicklens, and if we only consider .setTo, Chimney would only be missing foo.modify(_.list.at(idx)).setTo(item). If we could chain updates without any overhead, then we could get better performance than foo.modify(...).setTo(...).modify(...).setTo(...)),
Currently in a lot of of places we use
ctx.runtimeDataStore(idx)directly, whileTransformerConfiguration's overrides store onlyidx.We could move this extraction to
TransformerOverrides, so that the code would NOT hardcode how we are storing/parsing runtime information.TransformerOverrides would storeoverrideExpr: Expr[Any]instead ofindex: IntoverrideExprcould be computed inTransformerConfiguration.readTransformerConfigurationctx.runtimeDataStore(idx)could be replaced withoverrideExprThis way, in the future we could:
provide an alternative API without any runtime overhead:
(By alternative I am thinking a separate module or even a separate library - to avoid confusion from one-in-one API -
import dsl.*- and API split into components -auto.*+inlined.*+syntax.*- and then yet another API for inlined expressions without fluent API overhead like Ducktape's.)open up possibilities to reuse macros to provide e.g. lens-like functionality
(If we'd compare to e.g. Quicklens, and if we only consider
.setTo, Chimney would only be missingfoo.modify(_.list.at(idx)).setTo(item). If we could chain updates without any overhead, then we could get better performance thanfoo.modify(...).setTo(...).modify(...).setTo(...)),make it easier to reuse Chimney derivation engine in other libraries (from what we can see Teleproto already attempts such thing in https://github.com/moia-oss/teleproto/pull/321)