Hello,
When I thought about it some more it seemed to me that we needed a couple of
extra methods on the QueryDictionary in addition to what we discussed
earlier. It also seemed necessary to clarify what the implications of this
interface have on the Dictionary that it implements. Namely, how the #put
and #get methods behave based on the fact that the backing storage for
values is now a sequence. (Hope that makes sense)
This what I've come up with:
/**
* A dictionary that allows multiple values for the same key.
* <p/>
*
* Note that calling {...@link Dictionary#get(String)} returns the first
* {...@link String} in the underlying sequence for the given key.
* <p/>
*
* Note that calling {...@link Dictionary#put(String, String)} replaces the
* underlying sequence with a new sequence containing just the new
value.
* <p/>
*
* @author brindy
*/
public interface QueryDictionary extends Dictionary<String, String>,
Iterable<String> {
/**
* Retrieves a value at a specific index for a given key.
*
* @param key
* the key to use
* @param index
* the index to use
* @return the value at the given index or null if there is no value
at
* the given index
*/
public String get(String key, int index);
/**
* Return all the values for a given key.
*
* @param key
* the key
* @return the values
*/
public Sequence<String> getValues(String key);
/**
* Put a sequence of values for a given key replacing the underlying
* sequence with this sequence.
*
* @param key
* @param values
* @return
*/
public String put(String key, Sequence<String> values);
/**
* Add a value to the underlying sequence for a given key.
*
* @param key
* the key
* @param value
* the value
*/
public void add(String key, String value);
}
Right now I'm thinking the get(String, int) method is redundant if we're
returning the Sequence from the getValues method.
The reason I added the getValues method was because there has to be some way
to know how many values there are or we would have to return null from the
get(String, int) method, forcing the user to do a null-check-loop, which is
somewhat undifnified and really that method should throw an
ArrayIndexOutOfBounds exception if called with an index that doesn't exist.
Also, while this is an interface the implementation details are pretty much
tied down, so shouldn't this be a concrete class that the other classes
extend instead? They are marked as final so it isn't as though any further
inheritence would be possible.
Thoughts?
Cheers,
Chris
(off out for the rest of the day)
2009/5/22 Christopher Brind <[email protected]>
> Ah yes, of course. No problem, you too.
> Cheers
> Chris
>
> On 22/05/2009, Greg Brown <[email protected]> wrote:
> >>Ok, unless there are objections the classes will be renamed to
> >>- ResponseHeaders
> >>- RequestHeaders, and
> >>- Parameters
> >>
> >>respectively. I will also create a specialised dictionary that can
> >>hold a sequence of strings as suggested by Greg and use this as the
> >>basis of the request headers and parameter classes.
> >
> > Sounds good. Just to be clear, the ResponseHeadersDictionary should also
> > implement this interface - given this API, there's no need for it to
> > implement Dictionary<String, ImmutableList<String>>.
> >
> >>It will probably be Sunday before I get chance to make these changes
> >>now due to my hectic social life ;) so there's still time for more
> >>thoughts/comment.
> >
> > No worries. Have a great weekend. :-)
> >
> >
> >
>
> --
> Sent from my mobile device
>
