-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use MultiMap instead of HashMap for the parsed query params #57
Comments
If multimap can provide the flexibility of the full |
I think the additional methods provided by multimap could be provided by a trait that is impl'd for |
I don't see how you could implement for example .get(key) which returns Some(val)|None and not the whole vector, but maybe I'm missing something. And that is IMO the biggest win because the most common case is only having one value per key. The "custom" iterators could probably be implemented as a trait though. |
You'd have to rename it to |
@havarnov any update on this? Would you consider changing your multimap crate in such a way, or should I write my own version? |
Also missing voice of @reem |
My thoughts haven't really changed, if the API is as good as |
Havn't had time to look at think about this. I don't want to make MultiMap less convinent because that's the whole point. Hmm, let med look at it through the weekend. |
Sorry for the radio silence, haven't had time to look into this before now. I've made a version which uses MultiMap instead of HashMap: https://github.com/havarnov/urlencoded/tree/feat/multimap. Maybe it's easier to compare the options now.. |
Use multimap for the parsed query params instead of
HashMap<String, Vec<String>>
.Mulitmap is basically a thin wrapper around
HashMap<T, Vec<T>>
, but with (imo) a bit better api for using the values. Especially for the common use case of only having one value per key. E.g.:The text was updated successfully, but these errors were encountered: