Skip to content

Conversation

@WesselVS
Copy link
Contributor

zio-bson-magnolia has support for a configuration (in addition to annotations). We need this support in zio-schema-bson as well. Right now, I've only implemented discriminator and class name transformer support, since this is what my company needs.

@WesselVS WesselVS requested a review from a team as a code owner March 11, 2025 11:32
@plokhotnyuk
Copy link
Contributor

Hi @WesselVS,

Thank you for your contribution to the project! I appreciate the effort you've put into this pull request. I have a few suggestions to help ensure our codebase remains maintainable and evolves smoothly over time.

When dealing with configuration that may change or expand, it's generally a good idea to avoid using case classes. This is because adding new flags or options can break binary compatibility of the auto-generated methods, which would require manual fixes and potentially introduce a lot of boilerplate code, as seen here.

Instead, I recommend using a regular class with a private constructor and a builder API. This approach provides more flexibility and better supports future changes. You can find a great example of this pattern here.

If you're interested in learning more about designing libraries for easier evolution while maintaining backward binary compatibility, I highly recommend checking out this insightful talk.

Thank you again for your work, and I look forward to seeing your updates!

@plokhotnyuk plokhotnyuk merged commit d905927 into zio:main Mar 12, 2025
27 checks passed
@WesselVS
Copy link
Contributor Author

Hi @WesselVS,

Thank you for your contribution to the project! I appreciate the effort you've put into this pull request. I have a few suggestions to help ensure our codebase remains maintainable and evolves smoothly over time.

When dealing with configuration that may change or expand, it's generally a good idea to avoid using case classes. This is because adding new flags or options can break binary compatibility of the auto-generated methods, which would require manual fixes and potentially introduce a lot of boilerplate code, as seen here.

Instead, I recommend using a regular class with a private constructor and a builder API. This approach provides more flexibility and better supports future changes. You can find a great example of this pattern here.

If you're interested in learning more about designing libraries for easier evolution while maintaining backward binary compatibility, I highly recommend checking out this insightful talk.

Thank you again for your work, and I look forward to seeing your updates!

Hi, thanks a lot! I learned a lot from your response and the video.

@plokhotnyuk
Copy link
Contributor

plokhotnyuk commented Mar 12, 2025

@WesselVS I'm happy that it was helpful!

Please peek the latest release that is already available on the Maven Central and enjoy results your work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants