Closed Kobzol closed 3 years ago
I think this would be a good idea, we could put it in the discussion part. It is definitely useful to show what could be done to replace the anti-patterns, but in this case those are non-standards so still not very good I guess. At least it reduce from worse to still okay?
Indeed a built-in solution in the compiler would be better, or at least some sort of reflection API, which would help the mentioned creates reduce complexity/verbosity. But there is some interest in these crates, so mentioning them as a possible workaround sounds good to me, as it's already done in other parts of this book (full disclosure: I'm the maintainer of the delegate
crate).
It seems a good idea to me.
Maybe you can add them in the advantages
section, below the code example, since it already talks about "less boilerplate".
As an alternative there is the see also
section, too.
What do you think?
those are non-standards so still not very good I guess
I think that linking crates that help to solve our patterns problem is a really good idea.
I would probably add it to the advantages section, to say something like "A cleaner solution for avoiding method delegation boilerplate might be to use a dedicated crate, i.e. XYZ".
yes, go for it :)
The chapter about the Deref polymorphism anti-pattern could mention crates that help with trait/method delegation, such as https://docs.rs/delegate/0.5.1/delegate/ or https://lib.rs/crates/ambassador.
If you agree, I can send a PR.