Dagger2 VS amber-docs

There used to be a thing called "releasable references" which was that. It was removed, though: https://github.com/google/dagger/issues/1117

As said in the title, we will focus on the dependency inversion principle and one of its application : dependency injection. For production-ready applications, it would be better to rely on a framework and not implement its own container. For it, the java ecosystem have 3 frameworks available : Spring, Guice and Dagger.

At Reddit, we use Dagger 2 for handling dependency injection (DI) in our Android application. As we’ve scaled the application over the years, we’ve accrued a bit of technical debt in how we have approached this problem.

Confusing. I initially thought someone ported the Dagger DI framework to Python: https://dagger.dev/

I'm currently using Dagger and Anvil for my DI needs. It's been working really well, especially around what Anvil permits in terms of multibindings defined on the type declaration rather than in a module. For example:

Great job, I have been waiting for this feature/fix for a long time https://github.com/google/dagger/issues/2328

Dagger

Record patterns are one step on the path to general pattern matching utility. The bigger building block is general deconstructors. I recommend reading Functional Transformation of Immutable Objects by Brian Goetz. The idea of "withers" shown there requires deconstructors:

https://github.com/openjdk/amber-docs/blob/master/eg-drafts/...

This is the vague plan.

You may be joking but...

Here is the much more detailed version: https://github.com/openjdk/amber-docs/blob/master/eg-drafts/reconstruction-records-and-classes.md

This kind of pattern matching is discussed in the design notes: https://github.com/openjdk/amber-docs/blob/master/site/design-notes/patterns/pattern-match-object-model.md

True, but that only pushes the question of value down the line.

I'm curious about lenses because Java did have a serious problem that required a solution: working with "simple" data correctly was difficult. The chosen solution was ADTs, so we did buy into that. But the approach being explored for transforming records (https://github.com/openjdk/amber-docs/blob/master/eg-drafts/...) only works one level at a time rather than for an entire path. So I wonder how valuable it would be to have a solution for paths. If the answer is that it's mostly valuable for an approach we haven't bought into yet, then we might not need to consider it just yet.

Just a heads up, something like that spread operator is actually coming sooner or later to java: https://github.com/openjdk/amber-docs/blob/master/eg-drafts/...

Pattern matching (for records) is already a preview feature.