v0.8.5

Changelog:

• added quality of life utilities for partial.Result (#446)
• new Chimney logo thanks to @NoemiRozpara! (#447)

Announcement

The past year was fully dedicated to creating a reliable 0.8.x line:

• addressing the tech debt and sorting out the internals - it was needed not only to enable Scala 3 support but also
  to unblock any future work - both new features as well as bugfixes - in a codebase of evergrowing complexity. I'd argue
  that this was more of an issue than the differences between Scala 2 and Scala 3 macro API, even though from the outside
  it might see as if the changes in the macro API were the main showstopper
• providing a support for Scala 3 - it's the most visible outcome of 0.8.0 release
• providing new features - some of them requested years ago! - enabled by the internals refactor:
  • providing better support for Protobuf oneOf transformations
  • allowing Java Beans transformations (well, all classes with public primary constructor) to be customized just like case classes
  • supporting Java's Enums
  • allowing macros to look at inherited properties (opt-in)
  • allowing Patchers to share configration flags through implicits just like transformers
  • allowing users to customize derivation using nested fields (withFieldConst(_.foo.bar.baz, value), see the last example in each section in provided values and computed values)
  • allowing users to provide their own constructor instead of relying on a public primary constructor
  • allowing users to preview (and debug) the whole derivation logic and generated code
• making the experience of working with 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 optimizations
• providing better integrations for Protobufs and kicking off integration for Java Collections
• stabilizing the API so that every other version would be a breaking change - since 0.8.0-RC1 we started checking for binary
  backward compatibility (as source compatibility is checked by tests)

That work was enabled by the 0.7.x line when we introduced PartialTransformers - it was then that we understood that TransformerF while useful, are

• too complex for most of the users - who only need something slightly better than Either[List[String], A] and working OOTB
• and too constraining for us - while we could assume that F 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!