On 22 April 2017 at 01:32, Mark Thomas <markt_at_apache.org> wrote:
> I disagree with the convenient / inconvenient tags above.
>
> If a header has multiple values in the vast majority of cases the first
> thing the user is going to want to do is split it up into the individual
> values. I'd argue it makes more sense for the container to write that
> code once than have every user write that code.
>
Mark,
I called Map<String, List<String>> inconvenient as for the common case of
wanting a single value, the user must deal with a list. They must decide
if they are going to iterate, take the first element after a range check or
just trust it has more than 0 elements.
In the case that the field can have multiple values, they still need to
parse each value in the list as that to can be a CSV:
trailer: a,b
trailer: c,d
Would arrive as {"trailer"=["a,b","c,d"]}, or are you saying that the
container should parse values and return {"trailer"=["a","b","c","d"]}?
While this would be very convenient, it is a big difference to our handling
of getHeaders and may not be appropriate for all headers.
If the list value types are to provide parsed/split values, then I'm less
keen on them. As much as I think the container should have provided that
semantic, that horse bolted decades ago and we have ceded the
responsibility for that to frameworks and applications.
So I still like 1. Map<String,String> and a mostly sufficient
simplification of the trailer semantic. But if there is not universal
support for it (or for the list variants), then I think we have to look at
something like ugly but correct like 5. List<Map.Entry<String,String>>
regards
--
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com