Request for comments: Bug 6306820

[Michael McMahon]

Richard Kennard wrote:
> Michael,
>
>> Though I think we should stick with the uppercase convention.
> Agreed.
>> What are you suggesting here?
> Nothing different to what I have been saying before. HTML requires us 
> to have the 'multi-valued return' feature, but I think if the API 
> looks like...
>
>    class UrlEncodedQueryString
>    {
>        void append( String name, String value );
>        void set( String name, String value );
>        String get( String name );
>        List<String> getValues( String name );
>    }
>
> ...people are going to be 'Huh? What's the difference between get() 
> and getValues()? When I put() or add() Strings in a List or a Map I 
> don't need a get() and a getValues(), why do I need them here?'. 
> Whereas, if the API looks like...
>
>    class UrlEncodedQueryString
>    {
>        void appendParameter( String name, String value );
>        void setParameter( String name, String value );
>        String getParameter( String name );
>        String[] getParameterValues( String name );
>    }
>   ...it feels a little more familiar. People can say 'hey this is 
> weird, but it's the same kind of weird I'm used to from the Servlet API'.
I think I agree with respect to the names of the methods, but I think the
comment (from Mark) was only to do with the return type of the 
multi-valued getXXX().
He is saying that it should be a List<String> instead of a String[]. I 
think I agree with
him. There may be a conflict here between the desire to fit in with the 
Java SE API conventions
and the desire to remain "familiar" with existing Java EE APIs, but the 
CCC's policy will
be to stick with the Java SE conventions.

Thanks
Michael.