Hi, That's in now. Let me know what you think.
Cheers, Chris 2009/5/24 Christopher Brind <[email protected]> > Hi, > > That all makes sense. I should be able to commit something in the next few > hours. > > Cheers, > Chris > > > > 2009/5/23 Greg Brown <[email protected]> > > >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. >> >> I came to the same conclusion myself this morning. Here's what I came up >> with. It's similar to what you proposed, but may be slightly more consistent >> with Pivot's existing collection APIs. It basically merges the Dictionary >> and Sequence interfaces: >> >> public interface QueryDictionary >> extends Dictionary<String, String>, Iterable<String> { >> public String get(String key); // from Dictionary >> public String get(String key, int index); // new >> >> public String put(String key, String value); // from Dictionary >> public int add(String key, String value); // new >> public void insert(String key, String value, int index); // new >> >> public String remove(String key); // from Dictionary >> public String remove(String key, int index); // new >> >> public void clear(); // new >> >> public boolean containsKey(String key); // from Dictionary >> public boolean isEmpty(); // from Dictionary >> >> public int getLength(String key); // new >> } >> >> >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) >> >> Agreed. I think the behavior you documented for these methods is what >> developers would expect. >> >> >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. >> >> Actually, I'm thinking it could just be a concrete class backed by an >> instance of HashMap<String, ArrayList<String>>. We could try to enforce >> read-only access for the response data if we wanted to, but right now I'm >> leaning towards keeping it simple and making it read/write. We'd end up with >> three instances of HashMap<String, ArrayList<String>> and three >> corresponding instances of QueryDictionary to wrap them. >> >> Thoughts? >> >> Greg >> >> >> >
