URLEncodedQueryString

[Richard Kennard]

Michael,

Thanks for everybody's input! I will only reply to those points that 
need further discussion. I'll post a new version with the other changes 
people brought up.

 > We need to support both separator types in the same input strings. 
Though I thought that
 > the original separators had to be preserved, but it seems this is not 
the case.

We could change the design to preserve separators, however it would 
significantly complicate the class for no appreciable gain (eg. you 
would have to allow clients to say which separator they wanted when 
appending new parameters, have to keep those in a separate Map, etc). 
99% of the time people are just going to use &'s, I suspect.

 > use a setSeparator() method to determine which to use for output.

We used to do this in a previous version. Someone (Alan?) pointed out it 
was confusing because it wasn't clear whether the setSeparator() applied 
to just output or also while parsing. It was advised moving it to a 
parameter on toString() made this clearer.

 >> 3) Do we really need removeParameter. Isn't this the same as
 >>   setParameter(name, null)?
 > Yes, it is the same. We could remove removeParameter.

We could also remove String.contains() in favour of String.indexOf() != 
-1, but I think the same argument applies (eg. clarity of API).

 > Will the result of getParameterMap preserves the name order?

Yes. It returns a LinkedHashMap.

 > the order of (different named) parameters does not matter.

It does not matter for those APIs that return a Map (eg. the Servlet 
API). However unit tests benefit from a consistent ordering, as do 
client expectations (eg. if I append a parameter, I generally expect it 
to appear on the end). It is unclear whether semantically two query 
strings with the same parameters but in different orders should be 
considered the same. At the moment I (deliberately) return false for 
that. Should I maybe return true instead?

Regards,

Richard.