Repository navigation
Extract typemap functionality to its own crate? #299
Description
The typemap functionality used for the Extensions type seems generally useful. I'm wondering if it'd be possible to extract it into its own crate or to combine efforts with similar crates. A while back @reem created typemap for use in Iron, and @SergioBenitez created the state crate for us in Rocket. Both contain similar functionality. If someone wants a bare-bones typemap for use in their own library, it'd be nice if there was one implementation that was favored, and could be shared by the aforementioned crates.
Activity
jimmycuadra commentedon Feb 22, 2019
Just found another one: anymap by @chris-morgan.
carllerche commentedon Feb 22, 2019
Thanks for the thought. As you pointed out, there already are crates providing the functionality. Could you clarify the reasoning for creating a new one w/ the contents of the typemap used here?
jimmycuadra commentedon Feb 22, 2019
It's just that a typemap seems like a generally useful data structure, and I wasn't sure why the one in http was written from scratch rather than using one of the existing crates. It seems the one in http is more minimal, so I then wondered if it would make sense for http's implementation to form the basis of the other typemap crates. That way if someone wants a basic typemap data structure, there is a more obvious choice, and if they want a higher level built on a typemap, there are other options built on the same foundation.
Maybe it wouldn't be beneficial to the http crate per say, I just saw an opportunity to codify a pattern I've seen in multiple places to a single place, which seemed like it would be a benefit to the crates.io ecosystem.
seanmonstar commentedon Feb 22, 2019
As I originally wrote the
Extensionspiece, I'll add what my thinking was at the time: yes there are existing crates like typemap and anymap, but the amount of functionality they provide was a lot more than needed, and so for such a fundamental crate ashttp, I opted for just writing this tiny one internally.chris-morgan commentedon Feb 23, 2019
Splitting such things into their own crates is not, as some say, a fundamentally good thing; it’s a trade-off. For most applications, using a library like anymap or typemap will make sense, but for the fundamental HTTP library that people use, having it as an extra dependency does not seem worthwhile: it increases complexity and tends to slow down builds. I am, and have been from the start, strongly with Sean on
httpusing its own type rather than using another one or extracting its own into a separate crate.jimmycuadra commentedon Feb 23, 2019
Okay, thanks for considering the idea, everyone!
jplatte commentedon Feb 21, 2022
@seanmonstar Can this be reopened? axum has a potential use case for more extension functionality which the anymap crate would provide, which is now approaching 1.0 (there's a beta). See tokio-rs/axum#770.
seanmonstar commentedon Feb 21, 2022
I don't think the reasons have changed. It's still preferable to not include another public dependency. If there's a specific thing need of the
Extensionstype, we can discuss that in a new issue.