Scala library for boilerplate-free, type-safe data transformations
This release candidate contains all the functionality intended for 1.0.0 launch. Please help us testing it for bugs. If no bugs - requiring changes to API and breaking binary/source compatibility - are found, Chimney 1.0.0 is planned to be released at 23.05.2024. Then it will move from early-semver to proper semantic versioning.
If you are curious about the migration from 0.8.x you'll find the guideline here (tl;dr there should be nothing to worry about as long as you recompile).
Changelog since 0.8.x:
Transformer, PartialTransformer and partial.Result have all instances that make sense for themcats.Validated to partial.Result use the same convention as other types (using AsResult type class and asResult extension method introduced in 0.8.0)partial.Result and PartialTransformer one can combine values using sequential or parallel semantics (read about them in the docs!!!)Alternative type class to the list of provided instances, a few missed discipline tests were added (#465)Option unwrapping by PartialTransformer (#322, addressed by #477) (disabling that behavior by default is not planned)Unit could be considered setters (provides a better fix to #424, fixed in #485). If needed non-Unit setters can be opted-in
def methods or other inherited accessors that could be enabled with a flag (fixed in #485)withFieldConst(_.adt.matching[ADT.Subtype].either.matchingRight.collection.everyItem.map.everyMapValue, ...)
Option (matchingSome), Either (matchingLeft, matchingRight), Scala's collections (.everyItem, .everyMapKey, .everyMapValue) but it is planned to extends support for other collectionswithCoproductInstance in favor or withSealedSubtypeHandled and withEnumCaseHandled (fixed in #500) - old name is still available but it was @deprecated since it uses the term "coproduct" basically unknown outside of library writers crowdwrap = yes configwithConstructorPartial (fixed in #508)withContructorEither in PartialTransformers to make it easier to work with smart constructors based on Either[String, Type] (done in #509)_.matchingSome, _.everyItem, _.everyMapKey,_.everyMapValue to every collection provided through integrations APIChain, NonEmptyChain, etc through integrations API (#421, fixed in #511)Changelog:
withConstructorPartial (fixed in #508)withContructorEither in PartialTransformers to make it easier to work with smart constructors based on Either[String, Type] (done in #509)This pre-release is the fifth of the planned series of internal cleanups. The series is intended to make sure that when 1.0.0 is finally released it will not have any serious (known) issues that could be only addressed by breaking the backward compatibility. We will be really glad if you tested it, and let us know about any such issues while they are still easy to fix.
Changelog:
withCoproductInstance in favor or withSealedSubtypeHandled and withEnumCaseHandled (fixed in #500) - old name is still available but it was @deprecated since it uses the term "coproduct" basically unknown outside of library writers crowdwrap = yes configThis pre-release is the fifth of the planned series of internal cleanups. The series is intended to make sure that when 1.0.0 is finally released it will not have any serious (known) issues that could be only addressed by breaking the backward compatibility. We will be really glad if you tested it, and let us know about any such issues while they are still easy to fix.
Changelog:
withFieldConst(_.adt.matching[ADT.Subtype].either.matchingRight.collection.everyItem.map.everyMapValue, ...)
Option (matchingSome), Either (matchingLeft, matchingRight), Scala's collections (.everyItem, .everyMapKey, .everyMapValue) but it is planned to extends support for other collectionsThis pre-release is the fifth of the planned series of internal cleanups. The series is intended to make sure that when 1.0.0 is finally released it will not have any serious (known) issues that could be only addressed by breaking the backward compatibility. We will be really glad if you tested it, and let us know about any such issues while they are still easy to fix.
Changelog:
Unit could be considered setters (provides a better fix to #424, fixed in #485). If needed non-Unit setters can be opted-in
def methods or other inherited accessors that could be enabled with a flag (fixed in #485)This pre-release is the fourth of the planned series of internal cleanups. The series is intended to make sure that when 1.0.0 is finally released it will not have any serious (known) issues that could be only addressed by breaking the backward compatibility. We will be really glad if you tested it, and let us know about any such issues while they are still easy to fix.
Changelog:
This pre-release is the third from the planned series of internal cleanups. The series is intended to make sure that when 1.0.0 is finally released it will not have any serious (known) issues that could be only addressed by breaking the backward compatibility. We will be really glad if you tested it, and let us know about any such issues while they are still easy to fix.
Changelog:
Alternative type class to the list of provided instances, a few missed discipline tests were added (#465)Option unwrapping by PartialTransformer (#322, addressed by #477) (disabling that behavior by default is not planned)This pre-release is the second from the planned series of internal cleanups. The series is intended to make sure that when 1.0.0 is finally released it will not have any serious (known) issues that could be only addressed by breaking the backward compatibility. We will be really glad if you tested it, and let us know about any such issues while they are still easy to fix.
Changelog:
Transformer, PartialTransformer and partial.Result have all instances that make sense for themcats.Validated to partial.Result use the same convention as other types (using AsResult type class and asResult extension method introduced in 0.8.0)partial.Result and PartialTransformer one can combine values using sequential or parallel semantics (read about them in the docs!!!)This pre-release it the first from the planned series of internal cleanups. The series is intended to make sure that when 1.0.0 is finally released it will not have any serious (known) issues that could be only addressed by breaking the backward compatibility. We will be really glad if you tested it, and let us know about any such issues while they are still easy to fix.
Changelog:
partial.Result (#446)The past year was fully dedicated to creating a reliable 0.8.x line:
oneOf transformations
withFieldConst(_.foo.bar.baz, value), see the last example in each section in provided values and computed values)PartialTransformers smoother, so that people could move away from TransformerF -
having one dedicated result type make it easier to write reliable code without giving up on optimizationsThat work was enabled by the 0.7.x line when we introduced PartialTransformers - it was then that we understood that TransformerF while useful, are
Either[List[String], A] and working OOTBF is a monad or an applicative, the blackbox-ness of the arbitrary effect tied our hands when we wanted to optimize the code for the most common cases. Also we had to shove 1 or sometimes 2 extra type classes around in macros (TransformerFSupport and optional TransformerFErrorPathSupport - I wonder how many of you ever tried to provide your own instance for any of them rather than using some of the build-ins).The work we did back then was both to improve the UX and to make the eventual refactor easier. We had to plan ahead.
Just like we are planning ahead now. We want to get to Chimney 1.0.0 in 2024. This will stabilize the API and behavior for years, and stable libraries is what we need right now.
Getting stable means many good things: users would be able to fearlessly update dependencies, no migration guides from one version to another would be needed, tutorials and examples will not go out of date.
But it also means that whatever API quirks we have will be to stay. At best we could provide a better API and deprecate the old one, but any improvement which would require e.g. changing how implicits works, changing what is enabled by default, optimization requiring different API representation (even if for kinda-internal type) would be rejected.
That's also one of the reasons why 0.8.x line attempted to push out as many features as it could while keeping backward compatibility - to encourage people to try out 0.8.x and give us some feedback. So that we could make the good use of one last breaking change opportunity - the future 1.0.0-RC line - to address as many issues (fixable only with breaking changes) as possible before committing to stability for years.
Mind, that it doesn't mean that the work would stop (although at some point a mature library with a defined scope needs less and less attention). It also doesn't mean that update to 1.0.0 would require of you any serious rewrites - the vast majority of changes that I have in mind right now would not change your code, only how implicits and internal data structures are organized.
Still, some of the current behavior might be undesirable. It might make sense to change it. Perhaps some of the undesirable behavior might come from poor explanation what is the intended use case for e.g. PartialTransformers and lack of best practices and sources on how to use them. Then we will improve the documentation, write blog posts, do presentations. Or perhaps it is a legitimate concern, and changing that behavior for every user would save them more pain than it causes.
But we would only know about your pain points if you test how 0.8.x works for you and gives us some feedback, so if you are using Chimney and have some issues with it, or if something is preventing you from using it, let us know!
Changelog: