Alan,
I read some distinct 'themes' into your last e-mail. Please permit me to
respond to the 'themes', rather than your exact points:
1. java.net.URL
You said:
'I would suggest ignoring java.net.URL completely... is parse(URL)
needed? ... is apply(URL) needed? ... I believe naming conventions would
suggest this be should Url* instead'
I actually encounter java.net.URL quite often in my daily work - many
APIs seem to use it, and don't seem to offer a java.net.URI alternative?
I think it is still quite active and shouldn't be ignored?
2. Servlet API
You said:
'it's not clear to me why any of the method names need the word
"Parameter" in them... It's not clear to me that we have to be
consistent with the Servlet API.'
I think consistency with the Servlet API is important because it is the
only example in the JDK (well, Java EE DK) of an API that deals
specifically with www-form-urlencoded query strings: it is mature and
very familiar to many developers?
It also has some naming quirks around returning String versus String[]
for getParameter and getParameterValues. Those quirks are the necessary
because of the HTML spec, so I'd rather match the Servlet API's naming
quirks than introduce a brand of quirks of our own?
3. Separators
You said:
'Is this enum needed? ... maybe the create method can specify the
separator? ... what if [the query string to be parsed] uses a different
separator? ... Do you have examples in mind where a query would be
parsed using one separator but then converted to use a different separator?
I'm afraid I thought I'd explained this already? It's also in the JavaDoc:
"ALL separators are recognised when parsing query strings. ONE separator
may be passed to 'getQuery' and 'apply' when outputting query strings"
I agree on your point around removing 'getQuery' and just having 'toString'.
Regards,
Richard.
