Fix for Request set bodyFields, need to be able to have List<String> …

[rwrozelle]

…for a map value: #47

[rwrozelle]

Fix for #47

[nex3]

Hmm, returning a List<String> value here will break backwards-compatibility, as will changing the return type to Map<String, Object>. I'm also not sure that returning a map that may have list or string keys is the right API in the abstract; it would make it easy for code written assuming strings to crash or, worse, behave unpredictably if the browser caused a list to be returned instead.

I think the ideal solution here would be to have a sort of multimap class that implements Map<String, String> but allows []= to take a list and has a .getMultiple() method so users can opt in to getting multiple values. That sort of thing would also be really useful for headers. If you'd like to implement that (maybe in the collection package), it would be awesome; if you don't want to, maybe we should just make this feature write-only for now.

[rwrozelle]

Agree with your assessment, want evolved behavior rather than breaking behavior. Multi-map would solve problems in other areas as well. I'll need to bring myself up to speed on lower level details of Dart language and see if I can tackle this. I do want to try, and will let you know if I'm up to the challenge. Thanks

[rwrozelle]

Here is example code of what a MultiMap would look like (if I coded it)
https://github.com/rwrozelle/multimap

Is this what you are looking for? I've played around with using it in local copies of the http and http_server package and it definitely plays nicely with only minimal updates to existing code and backward compatible. I decided on using a parent/child component template because it was the least amount of work and I didn't heavily research the existing Mixin classes, so might need to add some "with" stuff on the class definition?

I'm having a heck of a time compiling the SDK, I need to build a new VM on my laptop to get everything lined up and don't have the time until next year, so I can't put together example of code integrated into Collections package.

[nex3]

Here is example code of what a MultiMap would look like (if I coded it)
https://github.com/rwrozelle/multimap

Is this what you are looking for? I've played around with using it in local copies of the http and http_server package and it definitely plays nicely with only minimal updates to existing code and backward compatible. I decided on using a parent/child component template because it was the least amount of work and I didn't heavily research the existing Mixin classes, so might need to add some "with" stuff on the class definition?

The behavior here looks more or less right. We can iterate on the details of the design in a separate CL.

I'm having a heck of a time compiling the SDK, I need to build a new VM on my laptop to get everything lined up and don't have the time until next year, so I can't put together example of code integrated into Collections package.

Good news: you don't have to add it to the SDK! The collection pub package is the place for new collection types these days.

[rwrozelle]

Not familiar with term: CL

I've forked the collection package and added my code, do I perform a pull request and reference the original issues?

[nex3]

Not familiar with term: CL

Sorry, that's a Google-ism for "pull request".

I've forked the collection package and added my code, do I perform a pull request and reference the original issues?

Yes please!

[rwrozelle]

This pull request is dependent upon dart-archive/collection#47 being accepted.

[natebosch]

dart-archive/collection#47 stalled out. Closing this for now.