(Slightly hijacking this thread to share about my comment for the same post on Reddit [1])
It's great to see you exploring some foundational patterns that closely align with the principles behind my work on Context-Generic Programming (CGP).
The structure of your `BlanketAdapter` and `Adapter` traits bears a strong resemblance to the concepts of provider traits and consumer traits in CGP. In particular, your use of the `Target` type is conceptually similar to how the `CgpProvider` associated type is used within a CGP context.
To illustrate the connection, I’ve put together a CGP-based reimplementation of your example. You can see the full code below or check it out as a gist at [3].
I hope this example helps to demonstrate how CGP builds on the same design ideas but generalizes them further. With CGP, the pattern becomes applicable to any trait, and the macros helps reduce a significant amount of boilerplate.
There’s definitely room to refine the example further — for instance, by extracting `load_state` into a separate trait so it can be reused across different implementations. I decided not to go too far down that path here, just to keep the example focused and easier to follow.
I really like this idea - I keep finding myself re-implementing something like it every time I hit the brick wall of blanket impls. I'll see if there's a good place to make use of it in some of my current work at Gel (mainly trying to develop an ergonomic system for building postgres-style wire messages right now).
A nice model solving a quite recurring problem. However this sounds a bit as over-engineering here, as two traits have exactly the same type signature.
(Slightly hijacking this thread to share about my comment for the same post on Reddit [1])
It's great to see you exploring some foundational patterns that closely align with the principles behind my work on Context-Generic Programming (CGP).
The structure of your `BlanketAdapter` and `Adapter` traits bears a strong resemblance to the concepts of provider traits and consumer traits in CGP. In particular, your use of the `Target` type is conceptually similar to how the `CgpProvider` associated type is used within a CGP context.
To illustrate the connection, I’ve put together a CGP-based reimplementation of your example. You can see the full code below or check it out as a gist at [3].
I hope this example helps to demonstrate how CGP builds on the same design ideas but generalizes them further. With CGP, the pattern becomes applicable to any trait, and the macros helps reduce a significant amount of boilerplate.
There’s definitely room to refine the example further — for instance, by extracting `load_state` into a separate trait so it can be reused across different implementations. I decided not to go too far down that path here, just to keep the example focused and easier to follow.
[1] https://www.reddit.com/r/rust/comments/1lovjej/comment/n0qh0...
[2] https://contextgeneric.dev/
[3] https://gist.github.com/soareschen/5b520eac0e818058cedfa2fbe...
I really like this idea - I keep finding myself re-implementing something like it every time I hit the brick wall of blanket impls. I'll see if there's a good place to make use of it in some of my current work at Gel (mainly trying to develop an ergonomic system for building postgres-style wire messages right now).
A nice model solving a quite recurring problem. However this sounds a bit as over-engineering here, as two traits have exactly the same type signature.