RE: [collections] pairs package name

2003-12-05 Thread Neil O'Toole
+1 - definitely the best so far. --- ASHWIN Suresh [EMAIL PROTECTED] wrote: I'll suggest keyvalue to positively describe the package (rather than negatively). That name allows MapEntry, KeyValue and MultiKey. (data/holders/elements all seem a bit vague) Stephen +1 Ashwin

Re: [collections] pairs package name

2003-12-04 Thread Phil Steitz
Stephen Colebourne wrote: I'll suggest keyvalue to positively describe the package (rather than negatively). That name allows MapEntry, KeyValue and MultiKey. (data/holders/elements all seem a bit vague) Stephen +1 Phil - To

RE: [collections] pairs package name

2003-12-04 Thread ASHWIN Suresh
I'll suggest keyvalue to positively describe the package (rather than negatively). That name allows MapEntry, KeyValue and MultiKey. (data/holders/elements all seem a bit vague) Stephen +1 Ashwin - To unsubscribe,

Re: [collections] pairs package name

2003-12-03 Thread Rodney Waldhoff
Why can't these all just go with the maps? On Wed, 3 Dec 2003, Stephen Colebourne wrote: The pairs package name is perhaps not quite right. I would like the package to hold all non-collection data structure: - MapEntry - KeyValue - MultiKey How about renaming the package to data? (no

Re: [collections] pairs package name

2003-12-03 Thread Stephen Colebourne
KeyValue is not directly associated with maps - its a free form key value pair. MultiKey could also be used in a List or Set. Stephen - Original Message - From: Rodney Waldhoff [EMAIL PROTECTED] Why can't these all just go with the maps? On Wed, 3 Dec 2003, Stephen Colebourne wrote:

Re: [collections] pairs package name

2003-12-03 Thread __matthewHawthorne
o.a.c.c.data could work. some other ideas: o.a.c.c.types o.a.c.c.elements Stephen Colebourne wrote: KeyValue is not directly associated with maps - its a free form key value pair. MultiKey could also be used in a List or Set. Stephen - Original Message - From: Rodney Waldhoff [EMAIL

RE: [collections] pairs package name

2003-12-03 Thread ASHWIN Suresh
data would be fine but somehow I feel a name like that is too generic. I mean, it's all data! So, the name did rather describe what the classes do with data. So, one might call it: oacc.dataholders Or, if that is long, how about just oacc.holders Or something that describes that these

Re: [collections] pairs package name

2003-12-03 Thread Rodney Waldhoff
Maybe I just need to dig into this more deeply, but I find any form of Pair or Object[2] class being exposed as a public interface of commons-collections a bit questionable. On Wed, 3 Dec 2003, __matthewHawthorne wrote: o.a.c.c.data could work. some other ideas: o.a.c.c.types